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1, DMXxXMON INTRODUCTION 
The name DMXMON is an acronym derived from the words: DataMover Cross 
MONitor. A cross monitor is a program that facilitates the preparation, 
execution, and debugging of programs on a slave processor much like the resident 
operating system facilitates these activities on the main system processor. 
When under the control of DMXMON, the MTU-13@ actually appears to be a 
68086-based system. Conversely, a running 68088 program is “fooled” into 
believing that it has direct access to all MTU-13@ peripherals by channeling 
these accesses through DMXMON. Most importantly, a 68868 program is given 
access to the powerful file and I/0 management functions of CODOS (which runs on 
the 6582) just as easily as if CODOS was running on the 68008. Thus with the 
DMXMON cross monitor, the user/programmer can interact with the 68068 slave 
processor just as effectively as if it were in fact the main processor and often 
even more effectively. In fact, when a 68688 program is running, the 6582 
serves as a peripheral processor, freeing the 68088 from I/0 chores and 
improving throughput. 


In the discussion that follows, a working Knowledge of CODOS concepts and 
commands as well as fundamental machine language concepts is assumed. 
Additionally, some terminology peculiar to the 68080 microprocessor will be 
used. It is thus recommended that the CODOS, Datamover, and MC4688a@ 
microprocessor manuals be handy while studying DMXMON. It is also helpful to 
actually try the examples using an MTU-138 equipped with a Datamover. 


oe | SUMMARY OF DMXMON CAPABILITIES 

DMXMON was designed to make all of the MTU-138@ facilities that are normally 
available to the 6582 programmer also available to the 68608 programmer. There 
are some additional facilities made possible by the Datamover’s shared memory 
slave processor architecture as well. DMXMON is truly an operating system 
itself so there is no need to obtain and learn a new operating system just to 
tap the power of the 68080 microprocessor. 


For the user, DMXMON offers the complete array of CODOS file maintenance 
commands such as FILES, RENAME, DISK, KILL, TYPE, and others. These operate 
exactly like their CODOS counterparts and in fact are implemented by "passing 
the command through" to CODOS for execution. The user can also execute the full 
array of standard utilities, the only requirement being that they do not 
interfere with memory used by DMXMON (see the appendix for memory maps). A user 
written 68808 program is executed simply by typing its name along with any 
required arguments, just as with a user 6582 program. Thus file maintenance and 
running 68088 programs is just as simple and straightforward with DMXMON as 6582 
programs are with CODOS. Most importantly, the commands and overall operational 
philosophy is unchanged, meaning that the user’s Knowledge about CODOS is 
directly applicable to the Datamover and DMXMON. 


For the programmer, DMXMON offers an extensive array of over 98 “supervisor 
calls" (SVC) that allow access to all of the CODOS and MTU-138 I/O functions. A 
68886 TRAP instruction followed by an ID number and arguments in the registers 
is the supervisor call mechanism. Since the ID numbers will never be changed, 
68806 programs can be independent of any changes that may be later made to 
DMXM 


For simplicity in programming, the standard start-wait-complete form of the 
SVCs may be used. With this form, the SVC processor maintains control until the 
requested operation is completed. For greater throughput, the "start only" form 
may be used which will return control to the user’s 68888 program as soon as the 
operation is started. Computation may then overlap execution of the 1/0 
operation. Later, when the SVC’s results are required, a “wait-complete" SVC 
may be executed. 


Although DMXMON is basically a single-user single-task type of operating 
system like CODOS, several features useful for multitasking-like operation are 
provided. For example, a timer may be started which wil] interrupt the 68668 
program at a set periodic rate or automatically increment a long word in 68808 
memory. When using start-only SVCs, an interrupt can be given when the SVC is 
complete. Even an interrupting Keyboard may be enabled whereby every Keystroke 
entered will interrupt the 68688. When enabled, the interrupting Keyboard 
remains functional even during other I/0 operations such as disk access. An 
interrupt handler in DMXMON sorts out these various interrupts and automatically 
vectors to the user’s service routines. Note that these extended features wil] 
never “get in the way" of minimum complexity programming if they are not used. 
Contrast this with most other 68668 based systems that seem to require a degree 
in Computer Science just to do simple 1/0 programming. 


One of the most significant features of DMXMON is its ability to rapidly 
copy a portion of Datamover memory into the MTU-138’s display memory. Total 
flexibility is offered whereby a rectangular "window" of any size in 68000 
simulated display memory may be copied into any size and position “viewport” in 
real 6562 display memory. This can occur either on demand by the 68008 program 
or may be performed automatically by the 6582 in the background with virtually 
no slowdown of the 68606 program. With the Datamover’s extremely large memory 
capacity, it is quite practical to define a virtual display space of 1000x1000 
pixels or more (that would be 128K or 1/2 the Datamover’s standard memory) and 
display a selected portion up to 480x256 pixels in less than 1/4 second. 


For the debugger, DMXMON offers an extensive array of memory manipulation 
commands, execution mode error messages, and program breakpoints. All of the 
standard CODOS memory manipulation commands such as SET, FILL, HUNT, DUMP, 
COMPARE, etc. are provided, the only difference being that they operate on 68880 
memory. Full 24 bit addresses are recognized as arguments of these commands and 
32 bit arithmetic is utilized when evaluating expressions. In addition, the 
contents of all 6888@ registers may be displayed and changed with the REG 
command. The 68888 microprocessor recognizes a number of "trap" conditions 
during execution such as illegal instruction, divide by zero, addressing error, 
and others. These are reported by DMXMON with an English error message showing 
the problem location and register contents. Up to 4 breakpoints may be set in a 
68888 program which will stop execution and print the register contents when 
encountered. Execution may be resumed after the breakpoint with all registers 
and status restored. The 68868 program trace feature is not used by DMXMON and 
therefore is available to user programs. User programs may run in either 
the 68868’s supervisor mode or user mode with the default being supervisor mode. 
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42 CONSOLE MODE 


Like any system monitor, DMXMON operates in two different modes. In the 
console mode, the DMXMON> prompt is displayed on the console which signifies 
that it is waiting for a command from the operator. This is exactly analogous 
to the CODOS> prompt seen in normal MTU-13@ operation. Below is a summary list 
of the available DMXMON commands. They are described in detail in later 
sections. Note that all commands in this list that deal with memory deal with 
Datamover (68688) memory, not 6562 memory. 


COMMAND FUNCTION 
BP [<address>] Set or clear a 68808 program breakpoint 
BP? Display currently set breakpoints 
BYE Return control to CODOS 
CALC <expression> Display value of <expression> in hex and decimal 
cobos Return control to CODOS 


COMPARE <arg like CODOS> Compare two memory blocks for equality 

COPY <args like CODOS> Copy memory contents from one area to another 
DUMP <args like CODOS> Display memory contents in hex and ASCII 

FILL <args like CODOS> Fill memory block with a constant 

GET <args like CODOS> Load file into memory and set PC to entrypoint 
GETLOC <args like CODOS> Display load addresses and entrypoint of file 
GO <args like CODOS> Start 68868 program execution 

GROUP <group #> Set group select register to specified value 
HUNT <args like CODOS> Search memory block for specified values 

NEXT <args like CODOS> Resume 68088 program execution after breakpoint 
REG [<reg id> <cnts>] Display or alter contents of 688008 registers 
RESET Reset the 68088 then restore 68868 DMXMON 

SAVE Cargs like CODOS> Save memory contents as a 68088 loadable file 
SET <args 1ike CODOS> Store specified values into memory 

? Cexpression> Display value of <expression>, same as CALC 


In addition to the Datamover specific DMXMON commands listed above, a 
number of frequently used CODOS commands are recognized as such and are passed 
through to CODOS for execution. These "pass-through" commands are listed below: 


COMMAND FUNCTION 
ASSIGN Assign a channel to a file or device 
BEGINOF Position a channel to beginning of data 
BOOT Exit DMXMON and reload CODOS operating system 
CLOSE Flush buffers and allow removal of a diskette 
COPYF Copy specified files 
DATE Set the date 
DELETE Delete specified files immediately 
DIR Display full name and size of specified files 
DISK Display remaining space and VSN of open drives 
DO Read commands from a file 


DRIVE Set default disk drive 


ENDOF Position a channel to end of data 

FILES Display all filenames on a specified drive 

FORMAT Erase and prepare a new disk 

FREE Unassign a channel and close its associated file 
KILL Delete specified files with operator verification 
LOCK Write protect specified file 

MSG Display a message on the console 

ONKEY Define a function Key legend and substitution string 
OPEN Allow access to disk in specified drive 

PROTECT Disallow alteration of memory used by CODOS 
RENAME Change the name of an existing file 

TYPE Display contents of a text file 

UNLOCK Allow write or delete of specified file 

UNPROTECT Allow alteration of memory used by CODOS 

WAIT Wait for specified time and continue 


Other CODOS commands and standard utility commands can also be passed through 
Ceven if the name is the same as a DMXMON command) by preceeding the command 
with a period. Thus the command .DUMP would display the contents of 6582 memory 
(standard CODOS DUMP) whereas just plain DUMP would display the contents of 
68868 memory. 


Finally, when 68@@8 programs are saved as a file by DMXMON using the SAVE 
command, they become “user defined DMXMON commands" which can be executed simply 
by typing their names. This is exactly analogous to saving 6582 programs with 
CODOS which then become user defined CODOS commands. 


It is also possible to set up "job files" of DMXMON commands which can be 
executed with a DO command. The job file may contain any DMXMON command, 
pass-through command, or user defined command and the effect will be same as if 
the commands were typed in from the console. 


Numerous errors are possible when commands are executed. When DMXMON 
detects an error, the command is aborted and an error message is printed on the 
console. When CODOS detects an error, the standard CODOS error message is 
printed and control is automatically returned to DMXMON which may display an 
additional message. In either case, another command may be entered when the 
DMXMON> prompt appears. 


All of the standard CODOS line editing functions are available when 
entering a command. These include cntl/B to recall previous commands, cntI/R to 
redisplay the current command, and function Key string substitution. In 
addition, all of the standard console display control functions such as cntl/S 
(stop display), cntl/@ (resume display), and cntl/C (abort command) are also 
provided. 


13 EXECUTION MODE 


DMXMON is in “execution mode" when a 688@@ user program is actually 
running. When in execution mode, the portion of DMXMON resident in the 6502 is 
waiting for an operation request from the 68668 portion of DMXMON. Supervisor 
calls from the user program are interpreted by 68888 DMXMON and then passed to 
6562 DMXMON for execution. If enabled, the display will be automatically 
refreshed from 68888 memory during execution mode. 


Transition from console mode to execution mode is triggered when a GO or 
NEXT command is executed. It is also triggered when an unrecognized command 
that is the name of a 68688 loadable file is encountered. In any case, the 
68686 hardware registers are first loaded from a save area in memory and then a 
JSR (JMP for NEXT) is taken to the specified address or PC contents or user 
command entrypoint. DMXMON then enters execution mode. 


Transition from execution mode to console mode may be triggered in a number 
of ways. The normal way is for the 68888 program to finish its task and exit 
with an RTS instruction or execute one of the two exit supervisor calls. 

Another way is for the program to encounter a breakpoint set by the operator. 
Any error condition detected either by the 6800@ hardware or by SVC execution 
will print a message, the register contents, and then enter console mode. The 
operator may also force an exit at any time by pressing the INT key. 


Four classes of supervisor calls are available to the 68808 programmer 
while in execution mode. The first class consists of 23 CODOS derived SVCs plus 
two additional "systems related" SVCs. CODOS SVCs related to number conversion 
and the 16 bit pseudo processor are not included since the 688600’s more powerful 
instruction set makes these functions trivial to program directly. One of the 
added SVCs will return the time of day as 8 characters (requires the MultI/0 
board) while the other returns the highest available Datamover memory address. 


The second class includes 38 SVCs related to operating the keyboard and 
character display directly. For regular “stream I/0" it is usually easier to do 
the I/0 through CODOS channels, but for for special purposes such as editors and 
menu selection programs, these SVCs allow total control of the Keyboard and 
display. There is even a line editing SVC and an SVC for generating an 
arbitrary tone with specified pitch, volume, and duration. 


The third class consists of 21 SVCs for graphic data input and display. 
Full access to the MTU-138’s light pen, 480x256 pixel mapped display, and key 
controlled cross-hair graphic cursor is available. SVCs are provided for 
drawing, erasing, and flipping lines, dashed lines, and points using either 
absolute or relative coordinates. The light pen SVCs return a hit flag and X 
and Y coordinates with 1 pixel resolution. 
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The last class of SVCs includes 18 functions that are unique to DMXMON and 
the Datamover. These are summarized below and described in detail in section 3. 


SVC_NAME FUNCTION 

READM Read an arbitrary 6582 memory location 
WRITEM Write an arbitrary 6562 memory location 
BLKRD Copy a block of $6582 memory to 68088 memory 
BLKWRT Copy a block of 68888 memory to 6502 memory 
CALLM Call an arbitrary 6582 subroutine 

SETWD68 Set 68888 display window parameters 

SETVP65 Set 6502 display viewport parameters 

RFSH1 Refresh the $502 viewport from the 68688 window once 
RFSHSR Start automatic refresh of the 6502 viewport 
RFSHSP Stop automatic refresh 

CPYDSP Copy 6582 viewport to 688688 window 

WAIT Wait for a specified time 

CLKON Start periodic interrupt at specified rate 
CLKOFF Stop periodic interrupt 

CNT ON Start periodic in-memory counter update 

CNT OFF Stop in-memory counter update 

KYBON Start the interrupting Keyboard 

KYBOFF Stop the interrupting keyboard 


CONSOLE MODE COMMANDS 
2ol STARTING AND EXITING DMXMON 


Assuming that a disk with DMXMON written on it is in drive @, it may be 
started simply by entering: 


DMXMON 


in response to a CODOS> prompt. You may optionally follow the DMXMON command 
verb with any other command and it will be executed immediately after DMXMON is 
loaded. After DMXMON is loaded (and the following command, if present, is 
executed), it will display: 


DATAMOVER RUNNING 
DMXMON> 


and wait for a command. The DATAMOVER RUNNING message indicates that the 
Datamover was successfully reset and that the 68608 portion of DMXMON is 
responding correctly. I the Datamover board does not start up properly, a 
message to that effect is printed instead but DMXMON will still be responsive to 
commands ¢except for GO and NEXT of course), presumably for troubleshooting. In 
most respects, DMXMON commands perform the same function as CODOS commands of 
the same name. The difference is that they refer to the Datamover’s memory 
instead of regular 6582 memory. 


You may exit DMXMON and return to CODOS by entering BYE and a carriage 
return, or by entering CODOS and a carriage return. When in console mode, the 
INT key will also exit DMXMON and enter CODOS. All three methods of exit are 
equivalent. Since virtually all CODOS functions and commands can also be 
executed from DMXMON, there is little need to leave DMXMON unless your work with 
the 68688 is complete or you wish to run a 6582 program that uses most of memory 
such as the Editor, Assembler, or BASIC. 
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VALUES AND EXPRESSIONS 


Many DMXMON commands require numeric values for arguments. In this case, 
either decimal or hexadecimal values may be used. Unless otherwise indicated, 
all numeric arguments are assumed to be in hexadecimal. To specify a decimal 
argument, use the prefix ".". If desired, the $ prefix can be used to clarify 
hex values. 


An arithmetic expression can be used anywhere a numeric value is called 
for, except for disk drive numbers. Arithmetic expressions may be formed using 
the usual operators: "+", "-", "XK", "/", and "\". "\" is the remainder 
operator. All expressions are evaluated left-to-right without any operator 
precedence. The value entered may not exceed 4294967295 decimal ($FFFFFFFF) or 
be less that -2147483648 decimal ($86860000) including any intermediate point in 
the calculation. There is no error message if overflow occurs but the result 
will be truncated to 32 bits. Note that 32 bit arithmetic applies only to 
DMXMON unique commands. CODOS pass-through commands continue to use 16 bit 
arithmetic since they are interpreted by CODOS. The following examples 
illustrate the evaluation of numeric expressions: 


186 evaluates as 256 decimal (188 hex) 


- 168 evaluates as 10@ decimal (64 hex) 
B+ 16 evaluates as 27 decimal (1B hex). Blanks are ignored after operators 
1+. 18X3 evaluates as 33 decimal (21 hex) 


$1498/.256 evaluates as 28 decimal (14 hex) 
4@BC\106+1 evaluates as 177 decimal (BD hex) 
-.37 evaluates as -37 decimal or 4294967259 decimal (FFFFFFDB hex) 


Where single byte values are required such as in the SET, FILL, and HUNT 
commands, an ASCII character may be specified by enclosing it in quotes, either 
single quotes (’) or double quotes ("). The same Kind of quotes must be used on 
each side. When an ASCII character is used, it must stand alone, it cannot be 
used as a value in an expression. 


Memory addresses in DMXMON always refer to the memory onboard the 
Datamover. These addresses are always byte addresses which is the 68060 
convention. In terms of 16 bit words, even addresses refer to the left byte and 
odd addresses refer to the right byte. The 256K of Datamover memory apppears to 
be contiguous from $60868 to $3FFFF (up to $FFFFF if the full 768K memory 
expansion is added). Thus when using DMXMON commands, you view the memory just 
as the 68608 views it, as one big contiguous chunk. There is no error message 
if you attempt to access non-existant memory. Addresses greater than $FFFFF (1M 
byte) are truncated mod $1608086. 


2.3 DMXMON COMMANDS 


Since DMXMON in command mode is primarily a program preparation and 
debugging tool, most of its commands deal with the convenient manipulation of 
Datamover memory. You will find most of these commands to be very similar if 
not identical to their CODOS counterparts. 


2.3.1 BP 
PURPOSE: To set a program breakpoint for debugging purposes. 


SYNTAX: BP [<address>] 
BP? 


ARGUMENTS: <address> = address of first word of instruction at which 
breakpoint is desired. 


EXAMPLES: BP 428A 


will set a breakpoint at address $88428A. Following a GO or NEXT 
command, when program execution reaches 428A, control will be 
returned to DMXMON which clears the breakpoint and then prints the 
contents of all registers (see the REG command description for the 
format of the register printout). Up to 4 breakpoints may be set 
simultaneously. 


BP will clear all breakpoints. 


BP? will print the addresses of all active breakpoints. 


NCTES: 1. BP works by temporarily replacing the op-code at the indicated 
location with a TRAP @ instruction. The original op-code is replaced 


when the breakpoint is cleared. 

2. Breakpoints may be placed anywhere, even at Supervisor Calls. They 
should only be placed at the op-code word of an instruction and 
must therefore be at even addresses. 

3. The register printout is preceeded by the keyword -BREAKPOINT- to 
indicate that entry into DMXMON was through a breakpoint. 


2.3.2 BYE 





PURPOSE: To exit DMXMON and return to CODOS. 

SYNTAX: BYE 

EXAMPLE: BYE 
will exit DMXMON and return to CODOS. Before exit, the 6562 interrupt 
vectors, cntl/C vector, and CODOS error processing is restored to 
normal. If timer or Keyboard interrupts had been started by a 68088 
program, they will be stopped. The CODOS command or the INT Key (when 
in console mode) can also be used to exit DMXMON. 

2.303 CALC 


PURPOSE: To evaluate an expression and display it in hex and decimal. 


SYNTAX: CALC Cexpression> 
? Cexpression> 


ARGUMENTS: <expression> = any valid expression as described in section 2.2. 


EXAMPLES: CALC .87%16@@ will display: $68657868 = 356352 
CALC -.27532 will display: SFFFF9474 = 4294939764 or -27532 
201345 will display: $686C1345 = 791365 


NOTES: 1. Since numbers with the most significant bit set may be + or - 
(depending on usage), both representations are printed. 


2.3.4 cobos 





The CODOS command is identical to the BYE command described in section 2.3.2. 


2.3.5 COMPARE 

PURPOSE: To determine if two blocks of memory are identical. 
SYNTAX: COMAPRE <from> <to> <dest> 

ARGUMENTS: <from> 


<to>d 
<dest> 


Starting address of first block 
Ending address of first block 
Starting address of second block 
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EXAMPLE: COMPARE C686 12FFF 15888 
will compare every byte of the block of memory from $C@8@ to $12FFF 
to the corresponding bytes in the block from $15886 to $i1BFFF. If 
the blocks are identical, DMXMON will display SAME. If the blocks 
differ, the address and content of the first byte which differs 
will be displayed and the comparison will terminate. 
NOTES: 1. The comparison proceeds from the low address upwards. 
2. The two memory blocks may overlap thus allowing one to search a memory 
block for a byte that differs from the rest. 
2.3.6 COPY 
PURPOSE: To copy a block of memory to another memory location. 
SYNTAX: COPY <from> <to> <dest> 


ARGUMENTS: <#rom> Starting address of the block to be copied. 


<to> = Ending address of the block to be copied. 
<dest> = Starting address of destination of the copy. 
EXAMPLE: COPY 180 2FF 2000 Copies $108 - $2FF to $2080 - $2i1FF 


COPY 3080 3968 3066+.5@ Moves the block from $3088 - $3988 up 5@ bytes 
NOTES: 1. The block to be copied may be any size. 


2. The destination for the copy may overlap the block being copied. The 
direction of copy is automatically adjusted so that the block is 
correctly moved. 


3. The direction of copy may be reversed by swapping the <from> and <to> 
arguments. 


223.7 DUMP 
PURPOSE: To display the contents of a block of memory in hex and ASCII. 


SYNTAX: DUMP <from> <tod> <device> 
<channel> 


ARGUMENTS: <from> = desired starting address 
<to> = desired ending address 
<device> = desired device on which to display the output. Defaults 
to the console. 
<channel> = desired channel on which to display the output. 


EXAMPLES: DUMP 1688 Displays 16 bytes of Datamover memory starting at 
$1688. 
DUMP 2168 211A Displays memory starting at $2108 and will include 
memory through $211A. 
DUMP @ FFFF P Dumps 64K bytes starting at @ The display will be 
output to the printer. 
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The display produced by these examples will look similar to: 


@123 45 6 ? 8 ? A BC OE FP 
682168 34 77 D7? 4B 20 68 56 78) §=4F 4B 20 46 45 4C 4C 41 39 4w.H..Vx OK.FELLA 
@6211@ S55 67 69 42 57 45 68 63 63 83 26 OG BB OB 10 26 Ug. BYE... weseuees 


Of course the actual values displayed will depend on the contents of memory. 


The 16 rightmost characters on each line are the ASCII characters for the line, 


with each non-displayable character converted to ".", including blanks. 


NOTES: 1. A complete line is always displayed even if the <to> address is in 
the middle of the line. 


2. Cnti/S may be used to temporarily suspend the display and cntl/Q@ will 
restart it. Cntl/C will terminate the display and return to DMXMON. 


2.3.8 FILL 





PURPOSE: To fill a block of memory with a constant. 


"“Ccharacter>" 
SYNTAX: FILL <from> <to> [=] <value> 
‘€character>’ 


ARGUMENTS: <from> Desired starting address to be filled. 
<to> Desired ending address to be filled. 
<value> = Numeric constant to be deposited into each byte. 


<character> = Single ASCII character to be deposited into each byte. 


EXAMPLES: FILL 1280 12FF 6 Fills every byte between $1206 & $12FF with $88. 


FILL 1688 3FFFF AA Fills all of Datamover user memory with $AA. 


FILL 1088 18000+.99 ’"’ Fills 188 (decimal) bytes starting at $1668 


with $22 Can ASCII ">. 

Notes: 1. As each byte is deposited in memory, it is read back to verify. If 
the expected value is not read back, the command is aborted at that 
point. 

2.3.9 GET 


PURPOSE: To load a Datamover memory image from a disk file. 


SYNTAX: GET <file> [:<drive>] [=<dest>...] 


ARGUMENTS: <file> Desired file name to be loaded into memory. The default 


extension is .6. 


<drive> = Drive number, 6-3. Defaults to default drive, usually @. 


<dest> Destination starting address for load to be used in lieu 
of the <from> address which was specified when the file 


was saved. 


EXAMPLES: GET MYPROG - Loads the file called MYPROG.6 into Datamover memory. 


It 


will be loaded into the same addresses from which it was 


saved. The 68886 PC will be set to the entrypoint 
specified when the file was saved. 
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GET OLDPROG.X:1 =1768 =1B@@ Will load the file OLDPROG.X from drive 1 into 
memory. The first block will be loaded starting at 
$1788 and the second block (if it exists) will be loaded 
starting at $1B@6 regardless of the address specified 
when the file was saved. Any additional blocks (should 
they exist) will be loaded into the addresses from which 
they were saved. 


NOTES: 1. The file to be loaded must be a Datamover loadable format file. This 
means that it must have been created by SAVEing it under DMXMON or by 
the DMXASM assembler. This is not the same format as a 6582 
loadable file. See section 5.3. 


2. The file may consist of several non-contiguous blocks of memory, all 
of which will be loaded. See the SAVE command for details. 


3. Naturally, the GET command with <dest> specified does not relocate 
any machine language code; it merely loads the memory image at a 
different location. If the 68808 code loaded was written to be 
position independent, it should run at the new location. 


2.3.18 GETLOC 





PURPOSE: To display the load addresses and entry point of a Datamover loadable 
file. 


SYNTAX: GETLOC <file> [:<drive>] 


ARGUMENTS: <file> = Desired file name. The default extension is .6. 
<drive> = Drive number, 8-3. Defaults to default drive, normally @. 


EXAMPLES: GETLOC PROG1 Will display the load addresses and entry point 
of the file PROGI.6. 


GETLOC MATHS8K.Q@:1 Will display the load addresses and entry point 
of the file MATHS8K.Q@ on drive number 1. 


The typical display format of the data is as follows: 


MATHS8K.Q@: 1=8681678 881888 862467 
612888 @13FFF 


where the value immediately to the right of the = is the entry point address. 
The next value is the beginning address of the first block and the third value 
is the last address of the first block. If additional blocks are present, the 
first and last addresses are listed on additional lines. 


NOTES: 1. If the file specified was not created by a DMXMON SAVE command or by 
the DMXASM assembler, it is probably not in Datamover load format and 
an error message will result. 


2. When using GETLOC to determine memory usage by a program, remember 


that programs may use additional scratch RAM other than that actually 
loaded. 


2.3.11 





SYNTAX: 


GO 
PURPOSE: To begin execution of a 68868 machine language program in Datamover 
memory. 
GO [<from)] 
: <from> = Desired starting address. Defaults to current value of the 


ARGUMENTS 


EXAMPLES: 


NOTES: 1. 


2.3.12 





PURPOSE: 


SYNTAX: 


program counter (as displayed by the REG command). 


GO Begins execution at the current value of PC. Note that a 
previous GET command will set PC to the entry point of the 
file loaded. 

GO 1868 Begins execution at $001008. 


Upon entry to the program, the registers will be set as displayed (or 
defined) by the REG command except for the system byte of the status 
register which will be forced to $27 (supervisor mode, trace off, 
interrupts disabled). If not previously defined, the registers will 
have unknown contents. When the program is entered the stack pointer 
will be set to $6884FC and can go as low as $8002C@. 


The program is actually entered by signalling the 680006 portion of 
DMXMON to set the registers and execute a JSR to enter the program. 
DMXMON then enters its execution mode. 


If the program terminates with an RTS to the top level, the registers 
(except PC) will be resaved and DMXMON will enter its console 

mode. This is useful for debugging subroutines since the REG and GO 
commands can be used to set up and enter the subroutine. The REG 
command can then be used to ascertain the results. 


GROUP 
To set the 6582 Group Select register (see section 2.2.3 in the 
Datamover hardware manual) to a specified value while executing CODOS 


pass-through commands. 


GROUP <group #> 


ARGUMENTS: <qroup #> = Group number to be selected. 


EXAMPLES: 


NOTES: 1. 


2. 


3. 


GROUP @ Selects Datamover memory group 8 ($80088@-$01FFFF) to be 
mapped into banks 2 and 3 of the 65@2’s address space. 


Group 5 Selects Datamover memory group 5 ($@A@@@6-$@BFFFF) to be 
mapped into banks 2 and 3 of the 6562’s address space 
(meaningful only if the Datamover’s memory is expanded). 


The group selection has no effect on any DMXMON commands; it only 
affects certain CODOS commands that deal with banks 2 and 3. 


Group @ is initially selected when DMXMON is started. 
The primary use for group selection is to allow moving data between 
any part of Datamover memory and 6582 memory. For example, the 


MTU-138 display memory may be copied into Datamover locations 
$3C068-$3FBFF by: 
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-GET IMAGE.G ;READ IMAGE INTO DISPLAY MEMORY 
GROUP 1 ;SELECT $200@8-$3FFFF TO BE IN BANKS 2 & 3 
-COFY C@6@0:1 FBFF C@@6:3 ;COPY IMAGE INTO DATAMOVER 


2.3.13 HUNT 





PURPOSE: To search a block of memory for a string of bytes. 


"€char>" 
SYNTAX: HUNT <from> <tod <value> eiaces 
“€chard’ 
? 


ARGUMENTS: <from> Starting address for the search 


<to> = Final address for the search 
<char> = An ASCII character 
<value> = A numeric value, 6-$FF 


Only one wildcard ¢?) may be used in a string. Maximum string 
length is 24 characters. 


EXAMPLES: HUNT 2066 2486 “DATAMOVER’ Will search memory from $2088 through 
$2468 inclusive and list the addresses of all occurrances 
of the ASCII string “DATAMOVER". When a match is made of 
all ? bytes, the starting address of the matching string is 
displayed and the search resumes at the next byte. 


HUNT 208 4438 ’GO’ ? "Paul’s" @D Will search memory from $268 
through $4486 for GO followed by any single byte followed 
by Paul’s followed by a carriage return. 


NOTES: 1. HUNT reports all occurrences of the target byte-string. CTRL/S may 
be used to temporarily stop the display and CTRL/@ to restart it. 
CTRL/C will terminate the command. 


2. Only one ? wildcard can be used and it cannot be the first byte of 
the search string (that would be meaningless). 


3. A ? inside an ASCII string is not a wildcard and will only match a 
? in memory. 


2.3.14 NEXT 





PURPOSE: To resume execution after a breakpoint, trap, or interrupt or to 
initiate execution of a 68868 program. 


SYNTAX: NEXT [<from>] 
ARGUMENTS: <from> = starting address, defaults to value of the program counter 


EXAMPLES: NEXT Will begin execution at the address currently in PC 
NEXT 32F6 Will begin execution at $8832F6 


NOTES: 1. The program is entered via a JMP instruction so that an RTS 
instruction will return to the address on the stack, not DMXMON. 


2. The difference between GO and NEXT is that GO initializes the stack 
and system status byte and enters the program with a JSR whereas NEXT 
enters with a JMP with the stack and system status byte preserved. 
The advantage of NEXT is that it enables a user to resume execution 
after a breakpoint, trap, or interrupt. 


14. 


2.3.15 REG 





PURPOSE: To display or alter the contents of the 68060’s registers. 
“Cchar>" 
SYNTAX: REG [<reg. desig.> [=] <value> soeed 
“<char>’ 
ARGUMENTS: <reg. desig.> = Register name to be altered: A@-Aé, D@-D7, PC, UP, 
SP, SR (A? is the same as SP) 
<value> = Desired numeric value or expression 


<char> Desired ASCII character 
EXAMPLES: REG Will display the register contents. 
REG A3=23680+. 168 Will set address register 3 to $8088023664. 


REG D@=6 Di=’A’ UP=2688 Will set data register @ to zero, data 
register 1 to $80606041, and the user stack 
pointer to $862000. 


NOTES: 1. The = between the register designator and the value is optional. 


2. The REG command without arguments displays the user’s registers in 
the format illustrated below: 


PC=8276B4 (BD7329A4) SP=688478 UP=@3FC88 SR=2705 
D@=8736 AF25 D4=274F A726 A2=6088 541C A4=864A FF45 
Di=FFFF FF6é7 DS=4142 4344 Ail=8000 8088 AS=A98G 472B 
D2=6686 29B5 Dé=88802 1743 A2=FFFF F721  Adé=8002 8000 
D3=28F4 8736 D7=4142 4344 A3=8001 FF76 


2.3.16 RESAVE 





PURPOSE: To resave one or more blocks of Datamover memory on a CODOS file. 
SYNTAX: RESAVE <file> (:<drive>] [=<entry>] <from> [=<dest>] <to> ... 


ARGUMENTS: <file> Desired file name, default extension is .6 


<drive> = Desired drive, 8-3, defaults to default drive, usually @ 

<entry> = Entry point desired, defaults to <from> 

<from> = Starting address for the block of memory 

<dest> = Address at which the block is the be loaded on subsequent 
GET commands, defaults to <from> 

<to> = Final address of the memory block 


NOTES: 1. RESAVE performs the same function as SAVE except that it is capable 
of replacing an existing file. See 2.3.18. 


2.3.17 RESET 





PURPOSE: To immediately halt and reset the 68008. 
SYNTAX: RESET 


EXAMPLE: RESET Will activate both the Halt and Reset hardware lines on the 
68668 thus immediately halting program execution at the end of 
the current machine cycle. All pending interrupts to and from 
the 68668 are also cleared. The 68688 portion of DMXMON will 
also be reloaded and the default settings of all DMXMON 
parameters will be reset. After reinitialization, the 68888 
portion of DMXMON will be restarted. 


iS 


2.3.18 SAVE 
PURPOSE: To save one or more blocks af Datamover memory on a CODOS file. 
SYNTAX: SAVE <file> U:<drive>] [=<entry>] <from> [=<dest>] <to> ... 


ARGUMENTS: <file> Desired file name, default extension is .6 


<drive> = Desired drive, 6-3, defaults to default drive, usually @ 
<entry> = Entry point desired, defaults to <from> 
<from> = Starting address for the block of memory 
<dest> = Address at which the block is the be loaded on subsequent 
GET commands, defaults to <from> : 
<ta> = Final address of the memory block 
EXAMPLES: SAVE DOIT 2886 2DFa@ 


saves the contents of memory locations $402000 through $802DF@ inclusive on a 
file called DOIT.é on drive @ (by default). Since no optional arguments were 
sepcified, the entry point will be saved on the file as $602008, the same as 
the starting address of the block. DOIT is mow a DMXMON user-command, so 
subsequently typing DOIT in response to a DMXMON> prompt will cause the block 
to be loaded from disk into memory at $2086 and execution begun at $2006. The 
GET command may also be used to reload the file into Datamover memory without 
executing it. 


SAVE RALPH_PROG.Q:1 =2424 2006 20FE 1348 13A8 


saves a file called RALPH_PROG.@ on drive 1. The file contains two memory 
blocks, the first from $862066 to $6628FE and the second from $001346 to 
$6013A8. The entry point is $@002424, 


SAVE SUBPKG.X 1468=3000 1466+.99 


saves 188 decimal bytes of memory on a file called SUBPKG.X, starting at 
$001468. Since a dest. address was specified, a subsequent GET SUBPKG.X 
command will cause the memory block to be loaded into addresses $3000 and up 
instead of the $14@@ address from which it was saved. 


NOTES: 1. The file is saved in DMXMON loadable format (see appendix) which is 
different from CODOS loadable format. 


Nh 


The existence of the "=" in the command indicates the existence of 
one of the optional arguments, <entry> or <dest>. Pay careful 
attention to the position of the arguments. 


3. When using <dest>, note that no relocation of any possible address 
references is made; the block saved is still an exact image of 
memory. Therefore specifying <dest> may not be a satisfactory method 
of relocating machine language programs. 


4. The entry point does not have to reside inside any of the saved 
blocks. 


5S. The number of blocks saved on a single file is limited only by the 
number of <from> <to> arguments you can fit on the command line. 


2.3.19 SET 





PURPOSE: To set the value of memory locations. 


"<char>...” 
SYNTAX: SET <from> [=] <value> ‘wie 
‘<char>..." 


ARGUMENTS: <from> = Address at which to deposit the first value 
<value> = Numeric value to be deposited 
<char> = An ASCII character to be deposited 


EXAMPLES: SET 1288@8=1B stores a $1B into Datamover memory location $812068 
SET 2866 "ABC" stores $41 into $2086, $42 into $2887, and $43 into 
$2688. 


SET 1288 88-.18 * . eae oe" sets location $1208 to $76, 
$1281-$1283 to $28 ASCII blank), $1284 to $6C, and 
$1285 to $22 (ASCII "). 


NOTES: 1. The = is optional and has no effect on the meaning of the command. 


2. As each byte is deposited in memory, it is verified by DMXMON. If 
reading the byte back from memory results in a bad compare to the 
value deposited, an error message is issued and the command is 
aborted. 


2.4 USER DEFINED COMMANDS 


When a Datamover 688668 program is saved as a file under DMXMON, it 
effectively becomes a DMXMON “User Defined Command". Simply by typing the 
program file name in response to a DMXMON> prompt, the user can cause the 
program to be loaded and executed automatically. Arguments can also follow the 
program filename on the command line, and if the program is written to do so, it 
can read and interpret those arguments. 


To familiarize yourself with this concept, start up DMXMON (see section 2.1) 
and then type in the following command exactly as written: 


SET 1608 4E 41 @ 2 2 “THIS IS AN INLINE MESSAGE’ @D @ 4E 75 


This is a short program using an SVC that will simply print a message on the 
screen and return when it is run. Now enter: 


GO 1686 
The message "THIS IS AN INLINE MESSAGE" should be printed on the screen 
followed by a DMXMON> prompt on the next line which verifies that the program is 
correct. Now enter this command to save the program on disk: 

SAVE INLINE 1688 1821 
This action turns the simple program into a user defined DMXMON command called 
INLINE. The actual filename saved (as reported by a FILES command) is INLINE.64. 


Now enter this command to erase the program from memory: 


FILL 1688 1621 FF 


a le 4 


You can verify that the program is no longer there by DUMPing the memory black 
or even trying the GO 1686 again (you will see the message "¥¥XNO USER VECTOR 

FOR EMULATOR OF CODESEXX" followed by a register printout if you do try the GO 
again). Now enter the following to execute your new user defined command: 


INLINE 


The program will be very quickly read from disk into memory and executed 
resulting in the "THIS IS AN INLINE MESSAGE" display. Note that user defined 
commands can be executed from a job file just like any other DMXMON command. 


2.5 CODOS PASS-THROUGH COMMANDS 


In addition to the Datamover specific DMXMON commands described in section 
2.3, a number of frequently used CODOS commands are recognized as such and 
"passed through" to CODOS for execution. The command function and syntax is 
exactly as described in the CODOS manual. The list of automatic pass-through 


commands is given below: 


COMMAND FUNCTION 
ASSIGN Assign a channel to a file or device 
BEGINOF Position a channel to beginning of data 
BOOT Exit DMXMON and reload CODOS operating system 
CLOSE Flush buffers and allow removal of a diskette 
COPYF Capy specified files 
DATE Set the date 
DELETE Delete specified files immediately 
DIR Display full name and size of specified files 
DISK Display remaining space and VSN of open drives 
DO Read commands from a file 
DRIVE Set default disk drive 
ENDOF Position a channel to end of data 
FILES Display all filenames on a specified drive 
FORMAT Erase and prepare a new disk 
FREE Unassign a channel and close its associated file 
KILL Delete specified files with operator verification 
LOCK Write protect specified file 
MSG Display a message on the console 
ONKEY Define a function key legend and substitution string 
OFEN Allow access to disk in specified drive 
PROTECT Disallow alteration of memory used by CODOS 
RENAME Change the name of an existing file 
TYPE Display contents of a text file 
UNLOCK Allow write or delete of specified file 
UNPROTECT Allow alteration of memory used by CODOS 
WAIT Wait for specified time and continue 


LS 


There are additional CODOS commands that have the same name as DMXMON 
commands such as DUMP, SAVE, SET, etc. The difference is that the CODOS command 
refers to 6582 memory while the DMXMON command of the same name refers to 
Datamover memory. You may force one of these ambiguous commands to be passed 
through to CODOS by preceeding the command name with a period. Thus the 
command: 


SET 5@@@ 12 34 56 78 
will write into Datamover memory at 5866 Chex) whereas the command: 
-SET 5088 12 34 56 78 


will write into 6582 memory just as if it were typed (less the .) in response 
to a CODOS> prompt. 


CODOS utility commands, $6582 user defined commands, and others not in the 
pass-through list above can also be executed from DMXMON by preceeding their 
name with a period. The only restriction in such usage is that they not overlay 
any memory used by DMXMON which is approximately $8854-@@AF in page zero and 
$6700-$4A0G in main memory. See the memory map in the Appendix for exact DMXMON 
memory usage. 
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3. EXECUTION MODE SUPERWI SoF ceLLe 





One of the primary functions of DMXMON is to provide a structured method 
whereby 68088 programs may access all of the software facilities of CODUS and 
all of the hardware facilities of the MTU-13@. Such an interface mechanism is 
necessary because the Datamover board itself has nao direct hardware access to 
any of these facilities. The SuperVisor Call (SVC) method chosen makes the fact 
that such 1/0 requests are processed through the 6562 transparent to 68008 
programs. 


Lee 
_ 


THE SVC MECHANISM 


The word SVC is a mnemonic for SuperVisor Call. An SVC is effectively a 
special Kind of subroutine call where the routine being called is specified by a 
function number rather than by a memory address. This is a very flexible method 
of identification because the actual subroutines can be moved around in memory 
without affecting the function numbers. 


The DMXMON SVC mechanism is very similar to the CODOS SVC mechanism. 
Instead of a 6502 BRK instruction followed by a one byte function number, a 
68668 TRAP instruction followed by a two byte function number is used. Unlike 
the 6582 however, the 68806 has 16 different TRAP instructions, distinguished by 
the low 4 bits in the TRAP op code word. DMXMON uses 4 of these traps (8-3) for 
SVCs and other functions as outlined below: 


TRAP @ Used for DMXMON breakpoints. 

TRAP 1 Used for the start-wait-complete form of SVs. 
TRAP 2 Used for the start form of SVCs, 

TRAP 3 Used to wait-complete a previously started SVC. 


For most programming, the start-wait-complete SVC form (TRAP 1) is 
appropriate. When the 63068 programmer needs to perform an 1/0 function, he 
codes the following: 


{previous instruction> 
TRAP 1 

DC .W <function #> 
{next instruction> 


When program execution encounters the SVC, control is passed to the DMXMON 
SVC processor which interprets the function number, performs the I/0 operation 
with the help of the 6562, and then returns to the instruction following the 
function number. Many SVCs require arguments to be passed in the A and D 
registers and will return arguments in these registers as well. Some will 
return yes/no information in the carry flag. SVCs will always preserve the 
machine registers not involved in argument passing including both stack pointers 
and both bytes of the status register. 


In the SVC descriptions, the size of arguments both passed and returned is 
given as either byte (.B), word (.W), or long word (.L). For passed arguments, 
a size designator of .W or .B indicates that the remaining 1 or 3 bytes of the 
register respectively are ignored. For returned arguments, a .W or .B indicates 
that the remaining 1 or 3 bytes of the register will be undefined. 


With the start-wait-complete form of SVCs, the user’s 68068 program is idle 
during the entire I/O operation. Computation can overlap SVC 1/0 however by 
using the techniques described in section 4.3. 


In the following sections, each SVC function number is given a mnemonic. It 
is recommended that the mnemonics be used in your programming so that SVC 
references will appear on the assembly cross reference listing. Equates for all 
of the SVC mnemonics may be found in the file called SVC480@0.A. 
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CODOS DERIVED Svcs 


The following SVCs are analogous to CODOS SVCs of the same function numbers. 
All of the important CODOS functions are provided but number scanning and the 16 
bit pseudo processor are not since these functions are trivial to program with 
the 68088’s more powerful instruction set. 


ID # MNEMONIC FUNCTION 

68 SVCRTS Display registers and return to DMXMON corsole mode 
61 SVCRET Return to DMXMON console mode 

62 SVCOUM Output an inline message over a channel 

@3 SVCINB Input a byte from a channel 

84 SYCQUB Output a byte to a channel 

65 SVCINL Input a line of text from a channel 

66 SVCOUL Output a line of text to a channel 

87 SYCOUS Output a string of text to a channel 

12 SVCDFB Get location of default I/0 line buffers and arguments 
13 SVCMON Execute any DMXMON monitor command 

14 SVCQCA Query the assignment of a specified channel 

15 SVCINR Read a record from a channel 

16 SVCOUR Write a record to a channel 

17 SYVCBOF Set the file position pointer to beginning-of-data 
18 SVCEOF Set the file position pointer to end-of-data 

19 SVCPSF Specify the file position randomly 

20 SVCQFP Determine the position of a file 

21 SYCASS Assign a channel to a device or a file 

22 SVCFRE Free a specified channel 

23 SYCTNC Truncate a file at the present file position 

28 SYCQUN Query the version number of DMXMON and CODOS 

29 SYCQFS Scan a file or device name to prepare for assignment 
38 SVCDAT Obtain the current 9 character date 

31 SVCTIM Obtain the current 8 character time 

32 SYCTOM Obtain the highest usable Datamover memory address 


$.2.1 SVCRTS 6 = $88 
PURPOSE: Display register contents and return to DMXMON console mode. 
ARGUMENTS: None 


DESCRIPTION: SVCRTS returns control to the DMXMON monitor with a display of the 
register contents. It is functionally equivalent to SVCRET except 
that the registers are displayed first. 


EXAMPLE : eaee 


TRAP 1 3 SVC 2 = PRINT REGISTERS & RETURN TO DMXMON 
DC.W 8 


3.2.2 SVCRET 1 = $81 
PURPOSE: Return to DMXMON console mode. 
ARGUMENTS: None 


DESCRIPTION: SVCRET returns control to the DMXMON monitor which then enters 
console mode and waits for a command from the operator. 


EXAMPLE : eens 
TRAP 1 3 SVC 1 = RETURN TO DMXMON 
DC.W 1 


3.2.3 SVCOUM 2 = $82 
PURPOSE: Output an inline message over a channel. 


ARGUMENTS: First byte after SVC = desired channel number. 
Second through Nth byte = desired ASCII message text terminated by 
a zero byte ($08). 


DESCRIPTION: SVCOUM can be used to display a message at any point in a program. 
It does not affect any registers. The message may be any length 
up to 64K characters and can contain any byte including 
unprintable characters except NUL ($68) which is the message 
terminator. Control will be returned to the instruction 
immediately following the @-byte terminator. The channel 
specified must be assigned to a valid device or file. 


EXAMPLE : eoee 
CMP.W D3,HILIM CHECK D3 AGAINST LIMIT 
BLE 1SOK BRANCH IF LESS THAN LIMIT 
TRAP i SVC 2 = OUTPUT INLINE MESSAGE 
DC.W 2 
dC.B 2 ON CHANNEL 2 
DC.B $@D,’ERROR-UPPER LIMIT EXCEEDED’ ,@ 
JMP GETN GO GET ANOTHER NUMBER 
ISOK .... 


This program segment will compare the contents of D3 with HILIM and print the 
message "ERROR-UPPER LIMIT EXCEEDED” if D3 is greater than HILIM. 


NOTES: 1. The message will always be displayed starting at the present 
position. If the message should start with a new line, then the 
carriage return should be explicitly included as in the example. 


2. DMXMON always resumes program execution at the next even addressed 
byte after the message (48088 hardware requirement). Most assemblers 
will also insure that the next instruction after the message wil] 
start at an even address. When hand assembling code, you are 
responsible for skipping an extra byte if the message is an odd 
number of bytes long. 


N 


ny 


3.2.4 SVCINB 3 = $43 
PURPOSE: Input a byte from a channel. 
ARGUMENTS PASSED: D1.B = Channel number 


ARGUMENTS RETURNED: D@.B 
CY 


= Byte received from the channel 

= Set means that channel was at end of file 

DESCRIPTION: SVCINB inputs a single byte from a selected channel, which must be 
assigned to a valid device or file. The value of the byte 
returned can be anything, including control characters ($88 to 
FF), if the selected channel is assigned to a file. If assigned 
to a normal, character-oriented input device, such as the 
Keyboard, then a CTRL/Z (ASCII SUB, $1A) will be interpreted as 
end-of-file. For files, end-of-file is true only when no more 
bytes can be read from the file. It is the programmer’s 
responsibility to check the status of the Carry after every SVCINB 
to ensure that end-of-file was not reached, The D@ register is 
not meaningfully returned if the Carry is set. 


EXAMPLE : cece 
MOVE.B #5,D1 SELECT CHANNEL 5 
TRAP 1 svC 3 = INPUT BYTE 
DC.W 3 
BCS EOF BRANCH IF END OF FILE 


CMP.B D@,#°C’ WAS INPUT CHARACTER A ‘C’? 


This program segment inputs a character from the file or device assigned to 
channel 5 and checks to see if it was an ASCII "“C". 


NOTES: 1. The remaining flags (other than CY) are not changed. 


2. Any value byte can be input aL $00, $08, $7F, $FF, etc. No 
editing characters are recognized. 


3. For applications requiring high-speed disk input of large amounts of 
data, SVCINR (15) is preferred to SVCINB. Since the SVC processor 
is called for every byte of input using SVCINB, the overhead 
involved limits throughput to less than 1008 bytes per second. 
SVCINR is capable of throughput in excess of 15,888 bytes per second. 


3.2.5 SVCOUB 4 = $84 


PURPOSE: Output a byte to a channel. 


ARGUMENTS PASSED: D@.B 
D1.B 


Byte to be output 
Channel number 


ARGUMENTS RETURNED: CY 


1 if at end-of-file after output operation 


DESCRIPTION: SVCOUB outputs the byte in D@ over the channel specified by D1. 
The channel must be assigned to a valid file or device. Although 
there is no need to do so, application programs may wish to test 
the Carry flag after SVCOUB to distinguish whether the character 
written was the last character of the file or was re-written over 
some other part of the file. If the channel is assigned to a 
device instead of a file, the Carry will always be returned set. 
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EXAMPLE : eee 
MOVE.B #2,D1 SELECT CHANNEL 2 
MOVE.B #$67,D@8 GET CHARACTER TO OUTPUT 


TRAP 1 SVC 4 = OUTPUT BYTE 
DC .W 4 
BCS EOF BRANCH IF WRITTEN AT END OF FILE 


This program segment outputs $87 over channel 2. Note that $@7 is not the 
character "7" but simply a byte with value 7. In channel 2 is assigned to the 
MTU-138 console display (the usual case), this will sound a short beep through 
the speaker since $87 is the ASCII BEL control character. 


NOTES: 1. The value $8@ (NUL) can be output using SVCOUB, as can any other 
possible 8 bit code. 


2. For applications requiring high-speed disk output of large amounts 
of data, SVCOUR (16) is preferred to SVCOUB. Since the SVC 
processor is called for every byte of output using SVCOUB, the 
overhead involved limits throughput to less than 1008 bytes per 
second. SVCOUR is capable of throughput in excess of 15,688 bytes 
per second. 


3. After you have finished writing to a file, it is good practice to 
FREE the channel. This ensures that the system buffer for that file 
will be "flushed" to disk and that the directory will be updated. 
Otherwise, the actual disk contents will not be updated until you 
CLOSE the disk or change the file position. See SVCFRE (22) for 
additional information. 


3.2.6  SVCINL 5 = $85 
PURPOSE: Input a line of text from a channel. 
ARGUMENTS PASSED: D1.B = Channel number 


ARGUMENTS RETURNED: D@.B = number of characters in the line 
CY = 1 if end-of-file was encountered immediately 
Line returned in input line buffer (pointer at $800268) 


DESCRIPTION: SVCINL inputs a line of text from the file or device assigned to 
the specified channel. The text will be deposited in a buffer 
whose address is specified in location $800268. The default 
buffer location is $800508, see section 3.2.9 for details. The 
line of text will be terminated by a CR ($@D). After the SVC is 
processed, the Carry will be set only if no characters could be 
read from the channel because end of file was encountered. The D@ 
register will contain a character count for the input line. This 
count does not include the $@D terminator. End of line is defined 
as the first carriage return ($8D) encountered. 


EXAMPLE: eeee 
MOVE.L #MYIBUF,$25@ SET UP ADDRESS OF INPUT BUFFER 
MOQVE.B #1,D1 SELECT CHANNEL 1 


TRAP i SVC 5S = INPUT LINE 
DC.W bs) 

BCS EOF BRANCH IF END-OF-FILE 
TST.B DO TEST FOR NULL LINE 
BEG ISNULL JUMP OUT IF SO 


This program segment inputs a line of text from channel 1 (normally assigned to 
the console) and places it in MYIBUF. It also tests for end-of-file and null 
line (only a carriage return). 


NOTES: 1. The line input cannot be longer than 192 characters (DMXMON uses 
CODOS’s default input line buffer). If SVCINL attempts to input a 
line with more than 192 characters, it will automatically add a 
carriage return after the 192nd character and return. 


2. When SVCINL is used to read from a channel assigned to the Console, 
all normal system editing characters (such as insert/delete, rubout, 
CTRL/B. etc.) will be in effect. If an attempt is made to input more 
than 192 characters from the Console, a short beep will be sounded 
and no more characters will be accepted for insertion. This affords 
the user the chance to backup and change the line, perhaps to make it 
fit in the 192 character limit. 


3. No editing characters are recognized when reading from any source 
other than the Console. 


4. Within DMXMON is a 256 byte area that may be used for an input line 
buffer. See the description for SVCDFB (12) for details. 


3. When maximum throughput is essential for reading disk files, you may 
wish to use SVCINR (15) instead of SVCINL. If you use SVCINR to read 
a large block from disk and then remove lines from the buffer 
individually as needed, throughput will normally be substantially 
enhanced. 


3.2.7  SVCOUL 6 = $86 
PURPOSE: Output a line of text to a channel. 
ARGUMENTS PASSED: D@.B = Number of bytes in line 


Di.B = Channel number 
(8808264) = address of buffer containing the text 


ARGUMENTS RETURNED: None 


DESCRIPTION: SVCOUL outputs a line of text over a channel which must be 
assigned to a valid file or device. Location $0080264 must contain 
a pointer to a buffer containing the text to be sent. The default 
output line buffer address is $888608, see section 3.2.9 for 
details. D@ must hold the number of characters to be sent, not 
including a carriage return which will be added automatically. 


EXAMPLE : eee 
MOVE.L #MYOBUF,$264 SET UP ADDRESS OF BUFFER 
MOVE.B LLNG,D@ GET LINE LENGTH 
MOVE.B #2,D1 SELECT CHANNEL 2 
TRAP | SVC 6 = OUTPUT LINE 
DC.W é 


This program segment will output a line of text in MYOBUF of length (LLNG) to 
channel 2 (normally assigned to the display). A carriage return will be 
appended to the text output from the buffer. 


NOTES: 1. The character count must be passed in the low byte of D@. This is 
normally convenient because D@ can be used as an index register that 
is incremented after each character is assembled into the buffer. 


2. Within DMXMON is a 256 byte area that may be used for an output line 
buffer. See the description for SVCDFB (12) for details. 


3. The difference between SVCOUL and SVCOUS (7) is that SVCOUL adds a 
carriage return after the line is output and SVCOUS does not. 


3.2.8 SVCOUS 7 = $87 
PURPOSE: Output a string of text to a channel. 


ARGUMENTS PASSED: D@.B = Number of bytes in string 
D1.B = Channel number 
(848264) = Address of buffer containing the text 


ARGUMENTS RETURNED: None 


DESCRIPTION: SVCOUS outputs a string of text over a channel which must be 
assigned to a valid file or device. Location $800264 must contain 
a pointer to a buffer containing the text to be sent. The default 
output buffer is at $8064600, see section 3.2.9 for details. D@ 
must hold the number of characters to be sent. 


EXAMPLE : eoee 
MOVE.L #MYOBUF ,$264 SET UP ADDRESS OF BUFFER 
MOVE.B SLNG,D@ GET STRING LENGTH 
MOVE.B #2,D1 SELECT CHANNEL 2 
TRAP 1 SVC 7 = OUTPUT STRING 
DC .W 7 


This program segment will output a string of text in MYOBUF of length (SLNG) to 
channel 2 (normally assigned to the display). The string will be output 
exactly as it appears in the buffer with no end-of-line character added by the 
system. 


NOTES: 1. The character count must be passed in the low byte of D@. This is 
normally convenient because D@ can be used as an index register that 
is incremented after each character is assembled into the buffer. 


2. Within DMXMON is a 256 byte area that may be used for an output line 
buffer. See the description for SVCDFB (12) for details. 


3. The difference between SVCOUS and SVCOUL (46) is that SVCOUL adds a 
carriage return after the line is output and SVCOUS does not. 
Naturally carriage returns may be embedded in the string itself if 
desired. 


3.2.9  SVCDFB 12 = $0C 


PURPOSE: Obtain location of system input line buffer, output line buffer, and 
arguments passed to user-defined DMXMON command. 


ARGUMENTS PASSED: None 


ARGUMENTS RETURNED: 868266 = address of input line buffer 
$800264 = address of output line buffer 
Arguments copied into input line buffer 


DESCRIPTION: SVCDFB installs the addresses of default DMXMON-supplied input and 
output line buffers into $808245@ and $008264 respectively. Each of 
these buffers is 256 bytes in length and is contained entirely in 
DMXMON memory between $880688 and $@@@FFF. SVCDFB also copies any 
arguments that may follow the DMXMON command that initiated 
execution of the program issuing SVCDFB. The arguments, if any, 
are are copied without leading blanks before the first argument. 

If there are no arguments, the first byte in the input line buffer 
will be a carriage return ($0D). 


EXAMPLE: seee 
TRAP 1 SVC 12 = ESTABLISH DEFAULT BUFFERS 
DC.W 12 


MOVEA.L $268,A@ TEST IF ANY ARGUMENTS PASSED 
CMP.B (AG) ,#$8D 


BEG NONE JUMP IF NONE 

CMP.B (AB) ,#’°Y’ TEST IF ARGUMENT IS "Y" 
BEQ ISY JUMP IF SO 

CMP.B (AGB) ,#°N’ TEST IF ARGUMENT IS "N* 
BEG ISN JUMP IF SO 

TRAP 1 OTHERWISE, ERROR 

DC.W 2 


DC.B 2,"ILLEGAL ARGUMENT", 13,8 


This program segment will establish addresses of the default buffers in 
locations $268 and $2464 and copy the command arguments into the input line 
buffer whose address is in location $268. If there are no arguments, a jump to 
NONE is taken. If the first argument is “Y" a jump to ISY is taken, if it is 
"N" a jump to ISN is taken and if it is something else, an error message is 
printed. For example, if the above program segment had been saved on a file 
and initiated by the DMXMON command: 


MYCOMD N 


then the character "N" would be first in the input line buffer and the program 
would jump to ISN. 


NOTES: 1. Any number of arguments using any syntax desired may be passed from 
the command line to the input line buffer. Copying starts with the 
first non-blank after the command name and ends when a carriage 
return is encountered. 


2. The address of the input line buffer that will be deposited into 
location $268 is $588 and the address of the output line buffer is 
$680. 


3. DMXMON does not use the default input and output line buffers for any 
purpose when in command mode. 


3.2.18 SVCMON 13 = $8D 
PURPOSE: To execute any DMXMON monitor command. 
ARGUMENTS PASSED: A® = Address of command string to execute 


ARGUMENTS RETURNED: None except register contents and memory locations that may 
be changed by the command’s own execution. 


DESCRIPTION: SVCMON (13) is the most powerful of all SVCs provided. Creatively 
used, it can give tremendous leverage to an application program. 
Simply stated, SVCMON calls the DMXMON monitor as a subroutine, 
with the command read from memory instead of channel 1 (normally 
the console). Each invocation of SVCMON will execute one DMXMON 
monitor command and then return to the invoking program in the 
normal manner. Thus a program can easily OPEN and CLOSE disk 
drives, FILL or COPY memory, GET, SAVE, or TYPE files, etc. 
Utilities and CODOS user-defined commands (6502 code) may also be 
executed in the usual manner. To use SVCMON, the desired command 
must exist as an ASCII string in memory terminated by a carriage 
return ($@D) and address register @ must contain the address of the 
start of this command string. 


EXAMPLE : ° 


MOVEA.L #DCMMD,A@ SET POINTER TO "DISK" COMMAND 

TRAP | SVC 13 = EXECUTE THE “DISK" COMMAND WHICH WILL 
DC.W 13 DISPLAY DISK VSN’S AND SPACE REMAINING 

TRAP 1 FOLLOW WITH QUESTION TO OPERATOR 


DC.W SVCMSG 
DC.B 2,$8D PRINT ON CHANNEL 2=DISPLAY 
DC.B “ARE THESE THE RIGHT DISKS AND IS THAT ENOUGH SPACE? “ ,@ 


TRAP 1 READ A BYTE FROM CHANNEL 1=KEYBOARD 
DC .W SYVCINB 
CMP D@,#°Y’ TEST IF “Y" REPLY 


DCMMD DC.B ‘DISK’ ,$@8D 


This program segment will first execute a "DISK" command which will display the 
volume serial numbers and remaining capacity of all open disks. It then uses 
SVCMSG (2) to print a question to the operator and SVCINB to read a single 
character reply which then determines the program’s future action. 


NOTES: 1. The command executed may be either a DMXMON command, a CODOS 
pass-through command (either automatic or forced with a period 
prefix), or a user-defined CODOS command (6582 code). A DMXMON user 
defined command (468888 code) should not be attempted. 


2. Since the return path to the invoKing program is stored on the system 
stack, the command executed must not redefine the system stack 
pointer except by normal usage of balanced JSR, RTS, pushes, pops, 
etc. 
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3.2.11 SVCQCA 14 = $HE 
PURPOSE: To query the assignment for a selected channel. 


Channel number 


ARGUMENTS PASSED: D1.B 


ARGUMENTS RETURNED: D@.B = Disk drive number if returned as 8-3; otherwise, 
returned as the single character device name. 


CY 1 if the channel is assigned, =@ if free. 


DESCRIPTION: SVCQGCA (14) enables a program to determine if a specified I/0 
channel is assigned or is available. If it is assigned, then the 
device or drive it is assigned to can also be determined. 


EXAMPLE : ier ene 
MOVE.B #5,D1 QUERY CHANNEL 5 
TRAP 1 SVC 14 = QUERY CHANNEL ASSIGNMENT 
DC .W 14 
BCC NOTASG JUMP IF NOT ASSIGNED 
CMP.B 06,#3 
BGT ISDEV JUMP IF ASSIGNED TO A DEVICE 
sees ELSE ASSIGNED TO A FILE 


This program segment determines the status of channel 5 and jumps to NOTASG if 
it is not assigned, jumps to ISDEV if assigned to a device, and continues if 
assiqned to a file. 


3.2.12 SVCINR 15 = $@F 
PURPOSE: To read a record from a channel. 
ARGUMENTS PASSED: D@.L 


D1i.B 
AG.L 


Number of bytes to read 
Channel number 
Starting memory address to receive the record 


ARGUMENTS RETURNED: D@.L = Number of bytes actually read 
AB.L = Address of last byte read, plus one 
CY = 1 if end-of-file encountered before any bytes could be 
read 


DESCRIPTION: SVCINR reads a block of bytes from a channel. Any size of block 
may be read and the size need bear no relation to the structure of 
the data read. 


EXAMPLE : coe 


MOVE.L #46888,D@ SET RECORD LENGTH = 40068 

MOVE.B #5,D1 SET TO READ FROM CHANNEL 5 
MOVEA.L #BIGBUF,A@ SET RECORD MEMORY ADDRESS 

TRAP j SVC 15 = READ RECORD 

DC.W 15 

BCS ISEOQF JUMP OUT IF FILE ALL READ 


CMP.L #4@886,D@ CHECK IF ALL ASKED FOR WAS READ 
BNE NOTALL 


This program segment reads 48,008 bytes from channel 5 into a buffer starting 
at BIGBUF. After the read, it jumps to ISEOF if no bytes were read because of 
end-of-file and jumps to NOTALL if at least 1 but fewer than 48,088 bytes were 
successfully read. 


NOTES: 1. 


a 


If the specified channel is assigned to a file, then reading begins 
at the current file position and continues until the specified number 
of bytes are read or end-of-file is encountered. Any type of data 
bytes may be read; there are no reserved end-of-record or end-of-file 
characters. 


If the channel is assigned to a device (not a file), then reading 
continues until the specified number of bytes are read or the 
end-of-file character (ASCII SUB = $1A = CTRL/Z2) is read. The CTRL/Z 
is not returned as part of the record in memory. 


If the Carry flag is returned set then no bytes at all could be read 
from the channel because end-of-file was encountered immediately. 


If the carry flag is returned clear than at least 1 byte was read 
before end-of-file. The actual number of bytes read is returned in 
D@. If D@ contains a smaller count than was specified but the carry 
remained clear, it indicates that end-of-file was encountered during 
the read operation. 


When reading large amounts of data from a file, using large records 
will significantly improve the reading speed. For example, if a 
program is to read 1088 8@-character records, the obvious way to do 
it is to use a loop which invokes SVCINR 1686 times with D@ set to 
8@. However a significant speed improvement can be realized by 
instead using, say, 188 SVCs of 88@ bytes each. By using large 
records it is possible to read in excess of 15,688 bytes per second 
continuous throughput from a file. 


The only practical limits to the record size is available memory 
(256K on the standard Datamover) and the capacity of a single 
diskette (iMbyte for 8" floppies). 


3.2.13 SVCOUR 16 = $16 


PURPOSE: To write a record to a channel. 


ARGUMENTS PASSED: D@.L 


ARGUMENTS RETURNED: CY 


Number of bytes to write 
Channel number 
Starting address in memory of record to write 


D1.B 
AG.L 


1 if the channel was positioned at end-of-file after 
completing the write. 


DESCRIPTION: SVCOUR writes a block of bytes to a channel. Any size of block 


EXAMPLE : 


may be written and the size need bear no relation to the structure 
of the data written. 


MOVE.L #5088,D@ SET RECORD LENGTH = 5008 


MOVE.B #6,D1 SET TO WRITE TO CHANNEL 6 

MOVEA.L #MIDBUF ,A@ SET RECORD MEMORY ADDRESS 

TRAP 1 SVC 16 = WRITE RECORD 

DC.W 16 

BCS NEWEOF JUMP OUT IF END OF FILE WAS EXTENDED 
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This program segment writes a record on channel 6. The recard to be written is 
5088 decimal bytes long and starts at MIDBUF in memory. After the write, it 
Jumps to NEWEOF is the write extended the size of the file assigned toa 

channel 6. 


NOTES: 1. If the specified channel is assigned to a file, then writing begins at 
the current file position. Any type af data bytes may be written; no 
special end-of-record characters will be written by the system. If 
the Carry is returned clear, it indicates that the file was nat 
positioned to end-of-file on the completion of the write operation 
(therefore part of the file must have been overwritten). 


2. If the channel is assigned to a device (not a file), then writing 
continues until the specified number of bytes have been output. 
The Carry flag is always returned set when writing to a device. 


3. Using large records will improve writing speed. For example, 
writing 18@ records of S@ bytes each takes longer than writing 14 
records of 800 bytes each. Continuous output to disk in excess of 
15,608 bytes per second is possible by using large records. 


4. After you have finished writing to a file, it is a good practice ta 
FREE the channel. This insures that the system buffer for that file 
will be "flushed" toa disk and that the directory will be updated. 
Otherwise, the actual disk contents will not be updated until you 
CLOSE the disk or change the file position. 


5S. The only practical limits to the record size is available memory 
(256K on the standard Datamover) and the capacity of a single 
diskette (iMbyte for 3" floppies). 
3.2.14 SVCBOF 17 = $11 
PURPOSE: To set the file position for a channel to beginning-af-data. 
ARGUMENTS PASSED: D1.B = Channel number 
ARGUMENTS RETURNED: None 
DESCRIPTION: After executing SVCBOF (17), a subsequent read or write operation 


will access the first data byte of the file assigned to the 
specified channel. 


EXAMPLE: eaae 
MOVE.B #4,D1 SET TO POSITION CHANNEL 4 
TRAP 1 SVC 17 = POSITION TO BOF 
DC.W 17 "REWIND" THE FILE 


This program segment positions the file assigned to channel 4 to 
beginning-of-data. 


NOTES: 1. If the selected channel is assigned to a device instead of a file, no 
action takes place. 


2. A file is always initially positioned to beginning-of-data when it is 
assigned. 


3. Executing SVCBOF will always result in a physical disk access, even 
if the file is already positioned at beginning-of-data. 
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3.2.15 SVCEOF 18 = $12 

PURPOSE: To set the file position for a channel to end-of-file. 

ARGUMENTS PASSED: D1.B = Channel number 

ARGUMENTS RETURNED: None 

DESCRIPTION: SVCEOF (18) positions the file assigned to the specified channel 


to end-of-file. A subsequent write operation would therefore 
append new data to the file. 


EXAMPLE : eee 
MOVE.B #8,D1 SET TO POSITION CHANNEL 8 
TRAP | SVC 17 = POSITION TO EOF 
DC .W 18 


This program segment positions the file assigned to channel 8 to end-of-file. 


NOTES: 1. If the selected channel is assigned to a device instead of a file, no 
action takes place. 


2. A file is always initially positioned to beginning-of-data when it is 
assigned. 


3. Executing SVCEOF will always result in a physical disk access, even 
if the file is already positioned at end-of-file. 
3.2.16 SVCPSF 19 = $13 
PURPOSE: To specify the file position for a channel. 


ARGUMENTS PASSED: D@.L 
D1.B 


Desired file position _ 
Channel number to position 


ARGUMENTS RETURNED: None 


DESCRIPTION: SVCPSF (19) positions the file assigned to the specified channel 
to the position specified by D@. 


EXAMPLE : eoee 
MOVE.L #7518,D@ SET POSITION TO ACCESS 7519TH BYTE OF FILE 
MOVE.B #6,D1 SET TO POSITION CHANNEL 6 
TRAP | SVC 19 = POSITION FILE RANDOMLY 
DC.W 19 
MOVE.B #° ’,D@ BLANK OUT THAT POSITION USING 
TRAP | AN OUTPUT BYTE SVC 


DC.W SVCOUB 


This program segment positions the file assigned to channel 6 to the 7518th 
byte and changes it to a blank. 


NOTES: 1. If the selected channel is assigned to a device instead of a file, no 
action takes place. 


2. A file is always initially positioned to beginning-of-data when it is 
assigned. 
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3. Executing SVCPSF will always result in a physical disk access, even 
if the file is already positioned at location specified by Dd. 


4. If the position specified by D&@ is beyond the current end-of-file, 
the file will be positioned ta the current end-of-file. 

S. The beginning of a file is position @, The next byte read when the 
position is @ will be the first byte of the file. Pasition 1 
represents the position after the first byte in the file. The next 
byte read when the position is 1 will be second byte, etc. 

3.2.17 SVCQFP 26 = $14 

PURPOSE: To determine the position of a file atsigned to a channel. 
ARGUMENTS PASSED: D1.B = Channel number to query 

ARGUMENTS RETURNED: D@.L = Current file positian 


DESCRIPTION: SVCQFP (20) returns the present file position for the specified 
channel in D@. 


EXAMPLE : eee 
MOVE.B #6,D1 SET TO QUERY CHANNEL 6 
TRAP 1 SVC 28 = QUERY FILE POSITIGN 
bC.W 26 
CMP.L = #65536,D@ CHECK IF BEYOND 54K 
BGE PG1 JUMP IF 50 


This program segment determines the position of the file assigned to channel 6. 
If it i¢ beyond 64K, then a branch to PG! is taken. 


NOTES: 1. If the selected channel is assigned to a device instead of a file, 
then D@ is always returned as $64606006. 

3.2.18 SVCASS 21 = $15 

PURPOSE: To assign a channel ta a device or a file. 

ARGUMENTS PASSED: Dé.B 


D1.B 
AGB.L 


Drive number or device name 
Channel number to assign 
Address of file name (applies to assignment to a file) 


ARGUMENTS RETURNED: D@.B = Byte of status information as follows: 


Bit 7 = Old flag. If set then file already exists. 

Bit $6 = File flag. If set, then channel assigned ta 
a file, not a device. 

Bit 5 = Locked flag. If set, then file is lacked 


(read only). 
DESCRIPTION: SVCASS (21) assigns the channel specified by D1 to the device or 


disk drive specified in D@ and file name specified by a string 
whose address is in AB. 


$3 


EXAMPLE: cece 
MOVEA.L #TNAME,A&® POINT A@ TO TEMP FILE NAME 


MOVE.B #1,D@ PUT FILE ON DRIVE 1 

MOVE.B #6,D1 SET TO ASSIGN CHANNEL 6 

TRAP | SVC 21 = ASSIGN CHANVEL TO A FILE 
DC.W 21 

BTST #7,D8 TEST IF FILE EXISTS 

BEQ ISNEW SKIP AHEAD IF IT DOES NOT EXIST 


TNAME DC.B “TEMP.D’ =NAME OF TEMPORARY FILE 


This program segment assigns channel 7 to a file called TEMP.D and jumps to 
ISNEW if the file had not been created previously. 


NOTES: 1. A® is not used if the channel is assigned to a device (not file). 
LEFT=8 REVIND=3 
2. The file name can be terminated by any character which is not legal 


in a file name. The extension may be included or omitted (in which 
case it defaults to .C). 


3. Assigning a channel to a file always positions the file to beginning 
of data. 


4. Assigning a channel which is already assigned automatically frees the 
old channel assignment before making the new assignment. 


S. The maximum length of the file name including the extension is 14 
characters. 


6. Drive numbers as part of the file name (:<drive>) are not recognized 


by SVCASS. See SVCQFS (29) for more information on file assignments. 


3.2.19 SVCFRE 22 = $16 

PURPOSE: To free a channel. 

ARGUMENTS PASSED: D1.B = Channel number to free. 

ARGUMENTS RETURNED: None 

DESCRIPTION: SVCFRE frees the channel specified by Di. If the channel had been 


assigned to a file, the file buffer will be flushed to the file 
and the disk directory will be updated. 


EXAMPLE : cece 
MOVE.B #6,D1 FREE CHANNEL 6 AND FLUSH BUFFER 
TRAP 1 SVC 22 = FREE A CHANNEL 
DC.W 22 


This program segment frees channel 6, flushes the file’s buffer in CODOS, and 
updates the directory. 


NOTES: 1. Freeing a channel which is unassigned results in no action. 

2. It is important that programs which write to disk always free the 
channel when the file is completed. Otherwise, if the disk is 
removed from the drive by the operator without a CLOSE command, the 
file could be incomplete. 
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3.2.28 SVCTNC 23 = $17 

FURPOSE: To truncate a file at the present file position. 

ARGUMENTS FASSED: Di.B = Channel number to ta truncate 

ARGUMENTS RETURNED: None 

DESCRIPTION: SVCTNC ¢€23) makes the present file position end-of-file. It is 
normally used to discard the unwanted end part of a file, or to 


discard the unwanted residual when overwriting an existing file 
with a shorter file. 


EXAMPLE : peae 
MOVE.L #81972,D8 POSITION FILE TQ 8K BYTES 
MOVE.B #4,01 FILE ASSIGNED TO CHANNEL 4 
TRAF i DO THE POSITION 
DC .W SUCPSF 
TRAP i SVC 23 = TRUNCATE FILE AT THAT POSITION 
DC.W 23 
TRAP 1 FREE THE CHANNEL 
DCW SUCFRE 


This program seqment truncates the file to a maximum of SK bytes of data. If 

the file contained less than SK of data, it would not be changed. If it 

contained more than SK of data, the rest of the file would be discarded. 

NOTES: 1. If the channel is assigned to a device instead of a file, mo action 
takes place. 


3.2.21 SVCQUN 26 = $1C 


FURPOSE: To return information about the version af CODOS and DMXMON which is 
running. 


ARGUMENTS PASSED: None 


ARGUMENTS RETURNED: D@.W = Information as follows: 


Bite 12-15 = DMXMON version number 
Bits 8-11 = DMXMON revision number 
Bits 4-7 = CODOS verzion number 
Bite 8-3 = CODOS revision number 


DESCRIPTION: SVCQVYN returns information about the particular version of CODOS 
and DMXMONM that is running. The least siqnificant byte identifies 
the CODOS version and the next byte identifies the DMXMON version. 
Each byte it split into two hex digits, HL which correspond to 
the version number, H.L. 


EXAMPLE: saee 
TRAP i DETERMINE OPERATING SYSTEM VERSION 
DC.W SYCQUN 
CMP.B 8 #%1F D8 TEST IF CODOS VERSION 2.8 


BGT 1SOK SKIP IF OK 
TRAP i CORRECT EFFECTS OF FILE BUG 
DC .W SYCOUM PRINT ERROR MESSAGE, NEEDED FEATURES NOT 


sees AVAILABLE IN EARLIER VERSIONS 


Ror 


This program segment determines whether the program environment is is less than 
version 2.@ for CODOS. If so, it prints an error message because the program 
uses some features that are not in the earlier versions. 


NOTES: 1. This SVC is useful when writing programs that depend on some version 
dependent feature or undocumented subroutine entrypoint. It allows 


the program to verify its operating environment if necessary before 
continuing. 


3.2.22 SVCQFS 27 = $1D 


PURPOSE: To scan a device or file name:drive in preparation for assignemnt to a 
channel or to ascertain a file’s status. 


ARGUMENTS PASSED: A@.L = Address of file or device name character string 


ARGUMENTS RETURNED: A@.L = Address of first byte after the name. 
CY is set if parsed name was a device name, clear if parsed 
name is a file name. 
D@.B = Information about the name as follows: 
For device name (CY set): 
Bit 7 set if specified device does not exist 
Bits 6-@ contain the ASCII device name (1 byte) 
For file name (CY clear): 
Bit 7? set if illegal mame or drive number 
Bit 6 set if specified drive is not open 
Bit 5 set if the file already exists 
Bit 4 set if the drive is write protected 
Bits 3 and 2 are not used 
Bits 1 and @ contain the drive number selected 


DESCRIPTION: SVCQFS (29) is a multi-purpose SVC which performs the following 
activities: 


1. It scans and validates an input string of characters specifying 
a file or device name. 


2. It returns status bits so that the application program can 
gracefully recover from common file/device specification errors 
without aborting the program. 


3. It helps setup the necessary registers for using SVCASS (21). 


SVCQFS is normally used to parse a character string which 
specifies the name of a file or device which is to be assigned to 
a channel for 1/0. SVCQFS scans the string, determines if the 
name is a device name or a file name, and checks it for legality. 


If the name is a legal device name, it checks to see if the 
specified device exists on the system. For example, a printer may 
or may not be present. The device name is returned in D@ so that 
the user may immediately use SVCASS to assign the device to a 
channel if all is in order. 


If the name is a file name, it is checked for legality. An 
optional drive number may be specified as part of the name if the 
name is terminated by a colon followed by a digit. Elanks may be 
present between the colon and the digit. If no drive it given as 
part of the string, the default drive (usually drive 8) will be 
assumed. If the file name (and optianally the drive number) are 
legal, then SVCQFS checks to see if the drive is open. If it is, 
then the disk is checked for write protection. The directory is 
then searched for the file name. The status bits of D@ return the 
results of these operations to the application program. Upon 
completion of SVCQGFS, the application program should verify that 
the status bits returned reflect the desired conditions. If they 
do, then all bits of D@ except @ and 1 should be masked off and 
SYCASS (21) invoked to assign the file. 


EXAMPLE: seee 
TRAP 1 USE STANDARD BUFFERS AND GET ARGUMENTS 
DC .W SVCDFB 
MOVEA.L $268 ,AB GET ADDRESS OF FIRST ARG ¢=NAME) IN AB 


TRAP 1 PARSE THE NAME 

DC .W SYCQFS 

MOVEA.L AB,A4 SAVE POINTER TO NEXT ARG FOR LATER 

BTST #7 ,D8 BRANCH IF ILLEGAL OR NON-EXISTANT 

BNE NOGCOD 

BCS ASGNIT BRANCH IF DEVICE SFECIFIED 

BTST #6 

BNE NOTOPN BRANCH IF SPECIFIED DRIVE IS NOT OPEN 

BTST #5 

BEG NOSUCH BRANCH IF NO SUCH FILE 15 PRESENT 

ANDI.B #$03,D8 ELSE DISCARD ALL BUT DRIVE NUMBER 
ASGNIT MOVE.B #5,D1 SET TO ASSIGN TO CHANNEL 5 

MOVEA.L $268 ,AB SET ADDRESS OF NAME IN AS AGAIN 

TRAP i DO THE ASSIGNMENT 


DC.W SVCASS 


This program segment first uses SVCDFB (12) to get the address of the system 
input buffer and a copy of the argument which is presumably a device or file 
name. It then uses SVCQFS (29) to parse the first argument encountered. The 
return arguments from SVCQFS are checked to make sure the file or device exists 
and is ready to be read. If everything is OK, then control passes to ASGNIT 
which assigns the file or device name just scanned to channel 5 in preparation 
for reading. If there is a problem with the syntax of the argument or the 
file/device name, branches are taken to appropriate error handling routines 
within the program (not shown). 


NOTES: 1. SVCQFS does not indicate whether a file is locked. The assign SVC 
(SVUCASS, 21) however does indicate the locked/unlacked status of a 
file when assignment of a channel to a file is completed. 


2. The total length of the file or device name, including blanks, must 
not be more than 2@ characters. 
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3.2.23 SVCDAT 36 = $1E 

PURPOSE: To obtain the current 9 character date. 

ARGUMENTS PASSED: A@.L = Address of buffer to copy the date into 
ARGUMENTS RETURNED: A@.L = Passed A@ + 9? 


DESCRIPTION: SVCDAT is used to obtain the current date as entered during the 
normal CODOS signon procedure or by execution of the DATE command. 
The date field will be 9 characters long and is stored in a buffer 
pointed to by A@. A@ is then incremented automatically by 9 in 
preparation for additional output into the same buffer. 


EXAMPLE: Lhe 
TRAP 
DC.W SVCOUM — OUTPUT MESSAGE ON CHANNEL 2 
DC.B 2,’TODAY IS ’,@ 
MOVEA.L #BUFF,A@ SET BUFFER ADDRESS IN A@ 
TRAP DETERMINE TODAY’S DATE 
DC.W - SUCDAT 
MOVEA.L #BUFF,A@ RESET A@ 


MOVE #9 ,DB SET 9 CHARACTER COUNT 
MOVE #2,D1 SET CHANNEL 2 
TRAP i PRINT THE DATE AND CR 


DC.W SVCOUL 


This program segment first prints on channel 2 (usually the display) using 
SVCOUM (2) "TODAY 1S ", then reads the 9 character date using SVCDAT into a 
buffer at BUFF, and then prints the date followed by a carriage return on 
channel 2 from the buffer using SVCOUL (4). 


NOTES: 1. The default date field is "XUNDATEDX". 
2. The exact format of the date is dependent on what the operator typed 
in when the system was started. It will typically be either 


DD-MMM-YY or M4/DD/YY with trailing blanks if the actual date is less 
than 9 characters. 


3.2.24 SVCTIM 31 = $1F 

PURPOSE: To obtain the current 8 character time of day. 

ARGUMENTS PASSED: A@.L = Address of buffer to copy the time into 

ARGUMENTS RETURNED: A@.L = Passed AG + 8 

DESCRIPTION: SVCTIM is used to obtain the current time from the MultI/0 board 
if it is present in the system. The time field will be 8 
characters long and is stored in a buffer pointed to by A®. AG is 


then incremented automatically by 8 in preparation for additional 
output into the same buffer. 


EXAMPLE: cone 
TRAP 1 

DC.W SYVCMOUM OUTPUT MESSAGE ON CHANNEL 2 
pc.B 2,°THE DATE AND TIME IS: ° ,6 

MOVEA.L #BUFF,A® SET BUFFER ADDRESS IN Aa 
TRAP 1 COPY DATE INTO BUFFER 

DC.W SYVCDAT 

MOVE.B #° “,¢€AQ@)+ PUT IN A BLANK SEPARATOR 
TRAP | COPY TIME INTO BUFFER 

DC.W SYCTIM 

MOVEA.L #BUFF,AG® RESET A@ 


MOVE #13,D6 SET 18 CHARACTER COUNT 
MOVE #2,D1 SET CHANNEL 2 
TRAP j PRINT THE TIME AND DATE AND CR 


DC .W SYVCOUL 


This program segment first prints on channel 2 (usually the display) using 
SsYCol" C2) "THE DATE AND TIME IS: ", then reads the 7 character date using 
SYCDAT (38) followed by the 8 character time using SVCTIM into a buffer at BUFF, 
and then prints them followed by a carriage return on channel 2 from the buffer 
using SYCOUL (4. 


NOTES: 1. The format of the time returned by SVCTIM is HH:MM:S5 on a 24-hour 
clock. 


2. If the Mult1/O board is not installed or does nat have the 
clock/calendar feature, the returned time will be 88:88:38. 


3.2.25 SVCTOM 32 = $26 





PURPOSE: To obtain the highest usable Datamover memory address. 
ARGUMENTS PASSED: None 
ARGUMENTS RETURNED: A®.L = Highest memory address that may be used 


DESCRIPTION: SVCTOM is used to determine the highest usable memory address. 
User memory under DMXMON extends from $@81886 through the value 
returned by SVCTOM. Typically, top-of-memory will be $@3FFFF for 
a standard Datamover and CODOS 2.@. See the notes for exceptions. 


EXAMPLE : coer 
TRAP 1 
DC.W SYCTOM DETERMINE HIGHEST MEMORY ADDRESS 
CMPA #26888,A@ TEST IF ENOUGH FOR IN-MEMORY SCRATCH 
BGE INMEM GO FOR IN-MEMORY SCRATCH IF SO 
sees OPEN A SCRATCH FILE IF NOT 


This program segment determines the top-of-memory and if it is less than 128K, 
sets up for using a scratch file on disk. 


NOTES: 1. For DMXMON version 1.8, the top-of-memory value will always be 
SO3FFFF unless it is patched to accomodate Datamovers with more or 
less than the standrad 256K of memory. 


2. Versions of CODOS later than 2.0 are expected to make use of part of 
Datamover memory as a "virtual disk". The value returned by SUCTOM 
with the companion version of DMXMON will be dependent on the current 
size of the virtual disk. 
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3.3 TEXT _ INPUT AND DISPLAY SVCS 





The following SVCs all perform functions related to direct input and output 
of text. The SVCs call the MTU-138 1/0 routines directly rather than through 
CODOS channel 1/0 as those in section 3.2 did and therefore offer greater 

fexibility at the expense of device dependence. 


Many of these SVCs implicitly use the text cursor. The text cursor’s 
location is defined by a pair of bytes that reside in 6582 memory. One of these 
bytes is the column (character) number the cursor is on and the other is the 
line number. Both of these start counting at one instead of zero. Since the 
cursor location bytes are not directly addressable by the 68000, SVCs are also 
provided to directly read and set the text cursor location. 


ID # MNEMONIC FUNCTION 

44 GETKEY Wait until a new Key is pressed and return its code 

65 TSTKEY Test if a new key is pressed, single recognition 

66 IFKEY Test if a key is pressed, multiple recognition 

6? INLINE Input a line from the Keyboard with editing allowed 

$8 EDLINE Display a line and allow editing using the keyboard 

6? CLRDSP Clear the entire 48@ x 256 display screen 

70 INITIO Clear screen, initialize Keyboard, restore I/0 parameters 
71 INITTW Clear screen, restore I/0 parameters 

72 DEFTW Specify the position and size of the text window 

73 REDTW Read the current size and position of the text window 
74 CLRHTW Clear the text window and home the cursor 

735 CLRTW Clear the text window only 

76 CLRTLN Clear a specified text line 

ve CLREOQL Clear from text cursor to end of line 

78 CLREOS Clear from text cursor to end of text window 

7? CLRLEG Clear the legend boxes from the display 

88 DRNLEG Draw the function Key legend boxes and the legends 

31 OFFTCR Turn the text cursor off 

82 ONTCR Turn the text cursor on 

83 FLPTCR Flip the video sense of the text cursor block 

34 SETTCR Arbitrarily set the text cursor position 

85 READTCR Read the current position of the text cursor 

36 CRLF Move the text cursor to left screen edge and down 1 line 
87 HOMETW Move the text cursor to upper left corner of text window 
38 CURUP Move the text cursor up 1 line if possible 

89 CURLFT Move the text cursor left 1 column if possible 

98 CURRGT Move the text cursor right 1 column if possible 

91 CURDWN Move the text cursor down 1 line & scroll if necessary 
92 OUCH Display a printable or interpret a control character 
93 BEEP Sound an arbitrary sounding beep 


Ce | GETKEY 64 = $48 
PURPOSE: Wait until a new Key is struck and return its code. 
ARGUMENTS PASSED: None 


ARGUMENTS RETURNED: D@.B = ASCII character code of key struck 
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DESCRIPTION: GETKEY will start scanning the MTU-138 Keyboard and wait for the 
operator to press a Key. During this time, a flashing cursor will 
ent t 


appear an the cisplay at the current text cursor location. The 
character typed is not echoed to the display. An audible click 
accompanies key depression if $562 memory location $213 is $60 Cit 
if $63 oy default>. See chapter & of the CODOS manual for 
additional parameters and details. The character code generated is 
MTU-138 extendec ASCII (see Appendix H of the CODOS manual). 
EXAMPLE: aietane 
TRAP 1 ; SVC $64 = GET A KEYSTROKE 
DC. 64 
CMP. #$H0,008 3 CHECK FOR CARRIAGE RETURN 
3.3.2 TSTKEY 65 = $41 





PURPOSE: Test if a new key is pressed; has multiple recognition lockout. 


ARGUMENTS RETURNED: 


DESCRIPTION: TSTKEY will sc 


an the Keyboard once looking for a Key that is down. 
If one it found dcwn that has not been previously recognized as 
Gown, its caoce is loa ded into D@.B and the carry flag is set. If 


wn 


d 
no new keys are found down, the carry flag is cleared and D@ is 
unchanged. The difference between this SVC and IFKEY is that a Key 
is recognized as down only once until the operator releases it. 
This aiso applies to a key still down after recognition by GETKEY. 





EXAMPLE: alsa 
TRAP 1 ; SVC $5 = TEST IF NEW KEY DOWN 
DCW 65 
BCC NCKEY ; SKIP AHEAD IF NO KEY PRESSED 
MOVE.B D@,KYCCD 3; PROCESS THE KEY CODE 
3.3.3 IFRKEY 66 = $42 
PURPOSE: Test if a Key it pressed without muitiple recognition lockout. 


ARGUMENTS PASSED: None 


ARSUMENTS RETURNED: CY 1 
DB.E 


a Key was pressed, @ = no Key pressed 
ASCII character code of Key 


DESCRIPTIGN: IFKEY will scan the Keyboard once looking for a key that is down. 
If one is found down, its code is loaded into D@.B and the carry 
flag is set. If no keys are found down, the carry flag is cleared 
and DB is unchanaed. he difference between this SVC and TSTKEY is 
that a key may be repeatedly recognized as being down as long as 
the operator holds it dawn. There will be a click each time the 
key is recognized as being down unless 6582 memory location $8213 
is set to $36. 


EXAMPLE : sues 
TRAP 1 3; SVC $6 = TEST IF KEY IS DOWN 
DC.W 66 
BCC NOKEY 3 SKIP AHEAD IF NO KEY PRESSED 
MOVE.B D@,KYCOD ; PROCESS THE KEY CODE 


NOTES: 1. When several keys are simultaneously pressed, the one earliest in the 
Keyboard scan sequence is recognized. 


3.3.4 INLINE 67 = $43 


PURPOSE: Input a line directly from the Keyboard with editing and previous line 
recall supported. 


ARGUMENTS PASSED: A@.L = Address of a buffer to receive the line entered 


ARGUMENTS RETURNED: D@.B = Number of characters in the line less the CR 
CY 1 = CTRL/2Z entered, @ = regular line entered 


DESCRIPTION: INLINE accepts one line of text from the Keyboard and allows all of 
the line-editing functions permitted by CODOS. Editing functions 
include CTRL/B for recalling prior lines, and automatic replacement 
of function Keys with pre-defined macro character strings. Once 
started, INLINE will not return until a complete line has been 
entered, terminated by a carriage return or CTRL/2 (Keyboard 
end-of-file) is entered. INLINE displays a cursor and echos 
characters typed to the screen. 


EXAMPLE : areas 
MOVEA.L #MYLBUF,A® SET BUFFER ADDRESS 
TRAP 1 SVC 67 = INPUT AN ENTIRE LINE 
DC .W 67 
BCS KEYEOF JUMP IF CTRL/2Z ENTERED 
TST.B DQ TEST FOR NULL LINE 


NOTES: 1. The difference between INLINE and SVCINL (5) is that INLINE accepts 
data only from the keyboard and it can use an arbitrary line buffer 
instead of the DMXMON system line buffer. 

2. See EDLINE (68) for a list of editing characters recognized. 


3. The maximun line length that may be input is 192 characters. 


3.3.5 EDLINE 68 = $44 
PURPOSE: To edit an entire line using the Keyboard. 


ARGUMENTS PASSED: A@.L 
Da.B 


= Address of a buffer containing the line to be edited 

= Initial number of characters in the line less the CR 

ARGUMENTS RETURNED: D#.B = Final number of characters in the line less the CR 
CY 1 = CTRL/Z entered 


DESCRIPTION: EDLINE is similar to INLINE (67) except that the input line buffer 
is assumed to already hold a line to be edited when EDLINE is 
called. The keyboard can be used to edit or accept the line. The 
full range of editing Keys accepted by CODOS is available. To use 
EDLINE, load the address of the line into A®@ and set D@ to the 
number of siqnificant characters in the line. A CR character at 
the end of the line is not required. EDLINE will alter D® to 
reflect the number of characters in the edited line. 


EXAMPLE: coor 
MOVEA.L #LINATT,A2 GET ADDRESS OF LINE ATTRIBUTE TABLE IN A2 
MOVE.W  LINNO,D3 GET LINE NUMBER INTO D3 

MULU #5,D3 MULTIPLY LINE NUMBER BY 5 

MOVEA.L 6(A2,D3) ,A@ SET BUFFER ADDRESS FROM TABLE INDEXED BY LINE# 
MOVE.B 4(A2,D3) ,D@ SET CHARACTER COUNT FROM TABLE 


TRAP i SVC 68 = EDIT THE LINE 
DC.W 68 

BCS KEYEOF JUMP IF CTRL/Z ENTERED 
CMP.B #6,D8 CHECK IF LINE DELETED 


This program segment illustrates a simple line editing application where line 
number LINNO is presented to EDLINE for editing. The address and length of the 
line are taken from a line attribute table that the overall editing program 
maintains. 


NOTES: 1. The use of EDLINE in conjunction with INLINE allows any interactive 
63868 program to offer sophisticated command line and statement line 
editing with very little programming effort. 


2. The editing characters accepted by EDLINE and INLINE are as follows: 
BACK SPACE Backspace 1 character 
Backspace 1 character 


RUBOUT Backspace 1 character then erase character under cursor 
Forward 1 space without erasing 

space Erase character under cursor then forward 1 space 

INSERT Enter insert mode, following characters are inserted 

DELETE Delete character under cursor and pull from right 

SHIFT Jump cursor to last character on line 

SHIFT Jump cursor to first character on line 

CTRL/B Delete current line and recall previous line(s) 

CTRL/E Toggle Keyboard echo to display on or off 

CTRL/R Recall current line from buffer to display 

CTRL/W Delete from cursor to end of line inclusive 

CTRL/X Delete line and put cursor at beginning 

CTRL/2 End-of-file for Keyboard input (first character only) 


3. The maximum line length that may be edited is 192 characters. 


3.3.6 CLRDSP 69 = $45 

PURPOSE: To clear the entire 256 x 48@ display screen. 

ARGUMENTS: None 

DESCRIPTION: CLRDSP will unconditionally clear the entire MTU-13@ display screen 
to black including the legend display area at the screen bottom. 


If you want to clear only the text window, use CLRHTW (74) or 
OUTCHR with an argument of $8C (form-feed). 
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EXAMPLE: snes 
TRAP i SVC 6? = CLEAR ENTIRE SCREEN 
DC .W 6? 


This program segment will clear the entire screen. 


3.3.7 INITIO 7@ = $46 


PURPOSE: To clear the screen, function Key legends, and backup buffer and 
restore default I/O routine parameters. 


ARGUMENTS: None 


DESCRIPTION: INITIO will completely re-initialize the text display driver and is 
useful if its previous state is unknown. It performs the following 
functions: 


1. Clears entire 48@ x 256 screen area. 

2. Clears all function Key legends to blanks. 

3. Clears function Key substitution strings to nulls ($88). 

4. Clears the “backup" buffer used to recall! previous lines. 

3. Draws the function Key legend boxes. 

6. Sets text window to 24 lines starting at the top of the screen. 
7. The text cursor is placed in the home position (COL=1, LINE=1). 
8. All text driver flags are set to their normal state. 

9. The Keyboard driver is initialized. 

1@. The audio DAC is initialized (may cause a speaker “pop"). 


EXAMPLE : eves 
TRAP 1 SVC 7@ = INITIALIZE TEXT I/0 DRIVERS 
DC.W 78 


This program segment will initialize the text I/0 drivers as described above. 


3.3.8 INITTWH 71 = $47 
PURPOSE: To clear the screen and set default values of display parameters. 
ARGUMENTS: None 


DESCRIPTION: INITTW will completely re-initialize the text display driver and is 
useful it its previous state is unknown. It performs the following 
functions: 


1. Clears entire 48@ x 256 screen area. 

2. Clears the “backup" buffer. 

3. Draws the function Key legend boxes and legends. 

4. Sets text window to 24 lines starting at the top of the screen. 
3. The text cursor is placed in the home position (COL=1, LINE=1). 
6. All text driver flags are set to their normal state. 

7. The audio DAC is initialized (may cause a speaker "“pop"). 


4.4. 


EXAMPLE : sees 


TRAP 1 SVC 71 = INITIALIZE TEXT WINDOW 
DC.W 71 


This program segment will initialize the text I/O drivers as described above. 


NOTES: 1. The differece between INITTW and INITIO is that INITTW does not affect 
the function Key legends or substitution strings and it does not 
initialize the Keyboard driver. 


3.3.% DEFTW 72 = $48 
PURPOSE: To specify the position and size of the text window. 


ARGUMENTS PASSED: D@.B = Number of text lines (1-25) 


Di.W = 255-Y where Y is the y coordinate of the topmost text 
line. 


ARGUMENTS RETURNED: None 


DESCRIPTION: DEFTW is used to define the position and size of the text window. 
D@ gives the number of text lines in the window with an allowable 
range of 1 to 25 (24 if function Key legends are to be displayed). 
Di specifies the position of the top text line in terms of 255-Y 
where Y is the Y coordinate of the topmost dot of the top line 
characters. The width of the text window is fixed at 88 
characters. 


EXAMPLE : sees 
MOVE.B #146,D8 SPECIFY 16 TEXT LINES 
MOVE .W #@,D1 STARTING AT TOP OF THE SCREEN 
TRAP 1 SVC 72 = SPECIFY SIZE AND LOC OF TEXT WINDOW 
DC.W 72 


This program segment will set the text window to 16 lines starting at the top of 
the screen. 


NOTES: 1. DEFTW will not move the text cursor itself but the next operation that 
does anything with the cursor will force it inside the new wondow if 
it was outside. 

2. The requested number of text lines must fit between the specified top 
position and the bottom of the screen (Y=6) at the rate of 18 
coordinate units per line. 

3.3.18 REDTW 73 = $49 

PURPOSE: To read the current position and size of the text window. 


ARGUMENTS PASSED: None 


ARGUMENTS RETURNED: D@.B 
D1i.W 


Number of text lines (€1-25) 


255-Y where Y is the y coordinate of the topmost text 
line. 
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DESCRIPTION: REDTW is the complement of DEFTW and returns the current size and 
position of the text window. It is useful for saving the display 
state when a program is started so it can be restored on exit. 


EXAMPLE : cues 
TRAP 1 SVC 73 = READ SIZE AND LOC OF TEXT WINDOW 
DC.W 73 

MOVE.B D@,OLDNL SAVE NUMBER OF LINES 

MOVE.W D1,OLDTL SAVE POSITION OF TOP LINE 


This program segment will save the current size and location of the text window 
so it can be restored later. 

Seael) CLRHTW 74 = $48 

PURPOSE: To clear the text window and home the cursor. 

ARGUMENTS: None 


DESCRIPTION: CLRHTW will clear the currently defined text window move the cursor 
to the home position. 


EXAMPLE : sees 
TRAP 1 SVC 74 = CLEAR TEXT WINDOW AND HOME CURSOR 
DC.W 74 


This program segment will clear the text window and home the text cursor. 
Display area outside the text window is not affected. 

3.3.12 CLRTW 75 = $48 

PURPOSE: To clear the text window only. 

ARGUMENTS: None 


DESCRIPTION: CLRTW sill clear the currently defined text window. The cursor 
remains in its present position. 


EXAMPLE: sees 
TRAP i SVC 75 = CLEAR TEXT WINDOW AND HOME CURSOR 
DC.W 73 


This program segment will clear the text window without affecting anything else. 


3.3.13 CLRTLN 76 = $4C 
PURPOSE: To clear a specified text line. 
ARGUMENTS PASSED: D@.B = Line number to clear 


ARGUMENTS RETURNED: None 


DESCRIPTION: CLRTLN will clear the line specified by D@. The line specified 
must be inside the text window. Lines are numbered from the top 
line down starting with one. The text cursor position is not 


affected. 
EXAMPLE: ae 
MOVE.B #1,D8@ SET UP TO CLEAR THE TOP TEXT LINE 
TRAP 1 SVC 76 = CLEAR TEXT LINE 
DC.W 76 


This program segment will clear the topmost text line in the text window. 


3.3.14 CLREOL 77 = $4D 


PURPOSE: To clear from the text cursor location to the end of the line the 
cursor is on. 


ARGUMENTS: None 


DESCRIPTION: CLREOL will clear the remaining portion of the text line the cursor 
is on. The character under the cursor is also cleared. This is 
useful when overwriting a text line with a new line that may be 
shorter than the old line. 


EXAMPLE: seen 
TRAP 1 SVC 77 = CLEAR REST OF LINE TO RIGHT OF CURSOR 
DC.W 77 


This program segment will clear all text to the right of the cursor. 


3.3.15 CLREOS 78 = $4E 


PURPOSE: To clear from the text cursor location to the bottom of the text window 


ARGUMENTS: None 


DESCRIPTION: CLREOS will clear the remaining portion of the text line the cursor 
is on. The character under the cursor is also cleared. Following 
this, all lines below the cursor to the bottom of the text window 
are cleared. 


EXAMPLE: sees 
TRAP 1 SVC 78 = CLEAR REST OF SCREEN BEYOND CURSOR 
DC.W 78 


This program segment will clear all text to the right and below the cursor. 
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3.3.16 CLRLEG 79 = $4F 
PURPOSE: To clear the legend boxes from the display. 
ARGUMENTS: None 


DESCRIPTION: CLRLEG will clear the bottommost 16 scan lines of the screen which 
is normally used to display the function Key legends. 


EXAMPLE : 


TRAP 1 SVC 79 = CLEAR LEGEND DISPLAY AREA 
DC.W 79 


This program segment will clear the legend display area. 


3.3.17 DRALEG 388 = $58 
PURPOSE: To draw the function Key boxes and legends. 


ARGUMENTS PASSED: A@.L = Address of 64 character string containing the legend 
text. 


ARGUMENTS RETURNED: None 


DESCRIPTION: DRWLEG erases the existing legend area (bottom 16 scan lines of the 
display area) and draws 8 legend boxes, each containing an 8 
character function Key legend. The boxes and legends are displayed 
in two groups of 4 like the function Keys on the MTU-138 Keyboard. 
The legends to be used are ASCII strings of exactly 8 characters 
each which are taken from a 64 byte buffer whose address is passed 
in A®. Non-displayable characters (control or bit 7 set) are 
treated as if they were blanks. The position of the text cursor is 
not affected. 


EXAMPLE : sees 
MOVEA.L #LEG3A,A@ SET ADDRESS OF LEGENDS FOR "OTHER" MENU 
TRAP 1 SVC 8@ = DRAW THE LEGENDS 
DC.W 88 


LEG3SA DC.B “ RECALL FIND MACRO FIGURE ’ 
DC.B “NEWPAGE UPDATE QUIT OTHER ’ 


This program segment will change the function key legends to those in LEG3A. 


3.3.18 OFFTCR 81 = $51 

PURPOSE: To turn the text cursor off. 

ARGUMENTS: None 

DESCRIPTION: OFFTCR is used for direct program control of the text cursor. When 
controlling the text cursor directly, it should be turned off 
before it is moved. Direct program control of the cursor is 


necessary when using the interrupting keyboard feature described in 
section 4.5. 
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EXAMPLE: 


This program 


TRAP 
DC.W 


segment will 


1 
81 


SVC 81 = TURN THE TEXT CURSOR OFF 


turn the text cursor off. 


NOTES: 1. If the text cursor is already off, OFFTCR will have no effect. 


3.3.19 


ONTCR 82 = $52 


PURPOSE: To turn the text cursor on. 


ARGUMENTS: None 


DESCRIPTION: ONTCR is used for direct program contro! of the text cursor. The 
text cursor is normally a reverse-video block that covers the 
character under the cursor. Turning the cursor on thus flips the 
video sense of the cursor block. To make the cursor flash, it must 
be alternately turned on and off or periodically flipped. Direct 
program control of the cursor is described in section 4.5. 


EXAMPLE: 


This program segment will 


TRAP 
DC.W 


1 
82 


SVC 82 = TURN THE TEXT CURSOR ON 


turn the text cursor on. 


NOTES: 1. If the text cursor is already on, ONTCR will have no effect. 


3.3.29 


FLPTCR 83 = $53 


PURPOSE: To flip the video sense of the text cursor block. 


ARGUMENTS: None 


DESCRIPTION: FLPTCR is used to flash the text cursor when performing direct 
program control of the text cursor. To make the cursor flash, it 
must be periodically flipped 2 to 6 times per second. Direct 
program control of the cursor is described in section 4.5. 


EXAMPLE : 


FLIP 


NWKY 


TRAP 
DC.W 
TRAP 
DC.W 
BCS 
MOVE .W 
TRAP 
DC.W 
TRAP 
DC.W 
JMP 
TRAP 
DC.W 


1 
ONTCR 
1 
TSTKEY 
NWKY 
47,00 
1 
WAIT 

1 

83 
FLIP 

1 
OFFTCR 


TURN THE TEXT CURSOR ON 

TEST IF NEW KEYSTROKE 

JUMP OUT IF SO 

WAIT 116MS = 4.3HZ2 FLASH RATE 
FLIP THE CURSOR 


GO FOR ANOTHER CYCLE 
BE SURE CURSOR IS OFF BEFORE MESSING 
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This program segment will turn the text cursor on and flash it at a 4.3Hz rate 
while testing the Keyboard for a Keystroke. When a Keystroke is detected, the 
cursor is extinguished and the character processed. 


NOTES: 1. If the text cursor is already on, ONTCR will have no effect. 


3.3.21 SETTCR 84 = $54 
PURPOSE: To arbitrarily set the text cursor position. 


ARGUMENTS PASSED: D@.B 
D1.B 


Column number (starts at 1) 
Line number (starts at 1) 


DESCRIPTION: SETTCR is used to move the text cursor to an arbitrary location in 
the text window. Note that the line and column numbers start at 1, 


net zero. 
EXAMPLE: seals 
MOVE.B #88,D@ SET COLUMN 82 
MOVE.B #3,D1 SET LINE 3 
TRAP 1 MOVE THE CURSOR TO THE RIGHT EDGE OF LINE 3 
DC.W 84 


This program segment will move the text cursor to the rightmost character 
position of text line 3. 


NOTES: 1. The new cursor position must be inside the text window. If it is not, 
it will be forced inside before it is used. 


2. Both the line and column numbers start at 1, not zero. 


3.3.22 READTCR 85 = €55 
PURPOSE: To read the current position of the text cursor. 
ARGUMENTS PASSED: None 


ARGUMENTS RETURNED: D8.B 
D1.B 


Column number Cleftmost is 1) 
Line number (topmost is 1) 


DESCRIPTION: READTCR is used to determine the present text cursor position. It 
is useful for saving the cursor location while an error message is 
displayed, etc. 


EXAMPLE: eeeae 
TRAP 1 READ THE CURSOR POSITION 
DC .W 85 


MOVE.B D@,CURLOC SAVE THE CURSOR LOCATION 
MOVE.B D1i,CURLOC+1 


This program segment will read the current cursor location and save it as a pair 
of bytes at CURLOC. 


ba @) 


3.3.23 CRLF 86 = $56 
PURPOSE: To move the cursor to the left screen edge and down 1 line. 
ARGUMENTS: None 


DESCRIPTION: CRLF will move the text cursor to the left screen edge and down one 
text line. If it is already on the bottom line of the text window, 
the display will be scrolled upward one line instead. CRLF 
performs the same function as displaying a carriage return code 
($@D) with QUCH (92). 


EXAMPLE : cess 
TRAP 1 DO A CR-LF 
DC.W 86 


This program segment will move the cursor down 1 line and to the left screen 
edge. 


3.3.24 HOMETW 87 = $57 





PURPOSE: To move the cursor to the upper left corner of the text window. 
ARGUMENTS: None 


DESCRIPTION: HOMETW will move the text cursor to the upper left corner of the 
text window. HOMETW performs the same function as displaying a $A4 
code with OUCH ($92), 


EXAMPLE: oes 
TRAP i HOME THE TEXT CURSOR 
DC.W 87 


This program segment will move the cursor to the home position. 


3.3.25 CURUP 88 = $58 

PURPOSE: To move the cursor up 1 line if possible. 

ARGUMENTS PASSED: None 

ARGUMENTS RETURNED: CY set if move was not successful, clear if it was 

DESCRIPTION: CURUP will move the text cursor up 1 text line if possible. The 
carry flag will be clear if the move was successful or set if the 


cursor is already on the top line. The display is not affected in 
either case. 


EXAMPLE : eeee 
TRAP 1 MOVE THE TEXT CURSOR UP 
DC .W 88 
BCC DIDMOV JUMP IF THE MOVE WAS SUCCESSFUL 


This program segment will try to move the cursor up one text line and then jump 
ta DIDMOV if the move was successful. 


3.3.24 CURLFT 89 = $59 

PURPOSE: To move the cursor left 1 column if possible. 

ARGUMENTS PASSED: None 

ARGUMENTS RETURNED: CY set if move was not successful, clear if it was 

DESCRIPTION: CURLFT will move the text cursor left 1 column if possible. The 
carry flag will be clear if the move was successful or set if the 


cursor is already at the left margin. The display is not affected 
in either case. 


EXAMPLE : cues 
TRAP 1 MOVE THE TEXT CURSGR LEFT 
DC.W 89 
BCC DIDMOV JUMP IF THE MOVE WAS SUCCESSFUL 


This program segment will try to move the cursor left one column and then jump 

ta DIDMOV if the move was successful. 

3.3.27 CURRGT 98 = $4 

PURPOSE: To move the cursor right 1 column if possible. 

ARGUMENTS PASSED: None 

ARGUMENTS RETURNED: CY set if move was not successful, clear if it was 

DESCRIPTION: CURRGT will move the text cursor right 1 column if possible. The 
carry flag will be clear if the move was successful or set if the 


cursor is already at the right margin. The display is not affected 
in either case. 


EXAMPLE : cone 
TRAP 1 MOVE THE TEXT CURSOR RIGHT 
DC.W 96 
BCC DIDMOV JUMP IF THE MOVE WAS SUCCESSFUL 


This program segment will try to move the cursor right one column and then jump 
to DIDMOV if the move was successful. 
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3.3.23 CURDWN 91 = $5B 





PURPOSE: To move the cursor down 1 line and scroll the display if necessary. 
ARGUMENTS PASSED: None 

ARGUMENTS RETURNED: CY set if the move resulted in a display scrol] 
DESCRIPTION: CURDWN will move the text cursor down 1 text line and scroll if 


necessary. The carry flag will be set if a scroll was necessary 
(cursor on bottom line) or clear if no scroll took place. 


EXAMPLE: sees 
TRAP 1 MOVE THE TEXT CURSOR UP 
DC.W 88 
BCS DIDSCR JUMP IF THE MOVE RESULTED IN A SCROLL 


This program segment will move the cursor down one text line and then jump 
to DIDSCR if the move resulted in an upward scroll of the text window. 


3.3.29 OUCH 92 = $5C 





PURPOSE: To display a printable character or interpret a control character. 
ARGUMENTS PASSED: D@.B = Character to display or interpret 
ARGUMENTS RETURNED: None 


DESCRIPTION: OUCH is the primary text display SVC. Through it, printable 
characters are displayed and most of the control functions can be 
effected with control characters. A complete list of the 
characters accepted by OUCH and their functions may be found in 
Appendix H of the CODOS manual. 


EXAMPLE : cose ; 
MOVE.B ¢A2)+,D8 GET NEXT CHARACTER TO OUTPUT 
TST.B D@ 
BEG EOM JUMP IF END OF MESSAGE 
TRAP 1 ELSE DISPLAY OR INTERPRET IT 
DC.W 92 
JMP OUTXT GO FOR ANOTHER 
EOQM wee. 


This program segment will display characters from a buffer pointed to by A2 
until a null character ($86) is found. 
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3.3.38 BEEP 93 = $5D 
PURPOSE: To sound an arbitrary sounding beep. 


ARGUMENTS PASSED: D@.L = Sound parameters as fallwos: 
Low byte = pitch, 1-255 
Mid low byte = volume, 6-127 
Mid high byte = duration, 8-127 
High byte is ignored 


ARGUMENTS RETURNED: None 


DESCRIPTION: BEEP will sound a tone in the MTU-13@’s speaker with controllable 


EXAMPLE : 


pitch, volume, and duration. The waveform is square. The pitch 
value specifies the waveform period in units of 20@uS. The volume 
ranges from @ (silence) to 127 with 64 being normal volume for an 
attention-getting beep. Duration is specified as the number of 
complete waveform cycles generated, therefore the duration in 
seconds is dependent on the pitch. Typical value for a polite beep 
is $086C4865 while a good value for a strident honk is $80507F20. 


MOVE.L #$507F28 SOUND A "YOU BLEW IT BUDDY" BEEP 
TRAP 1 
DC.W 93 


This program segment will sound a loud, irritating honk. 


NOTES: 1. The sound of long beeps will be affected somewhat if the timer, 


counter, or interrupting Keyboard is enabled. 
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GRAPHIC DISPLAY SVCS 


The following SVCs all perform functions related to the input and output of 
graphic information. These SVCs call the MTU-13@ graphic 1/0 routines directly 
since there is no channel I/0 support through CODOS for graphic information. 


Most of these SVCs implicitly use the graphic cursor. The graphic cursor’s 
location is defined by a pair of 16 bit words that reside in 6582 memory. One 
of these words is the X coordinate and the other is the Y coordinate. For the 
present MTU-13@ display implementation, the X coordinate may range from @ 
through 479 and the Y coordinate may range from @ through 255. Note that 
although the Y coordinate value can be represented with a single byte, a full 
word should be used as with the X coordinate to minimize compatibility problems 
with future display upgrades. Since the cursor location bytes are not directly 
addressable by the 68868, SVCs are also provided to directly read and set the 
graphic cursor location. 


All graphic SVCs verify that the coordinates are in range before an 
operation is performed. If one or both are out of range, the offending 
coordinate is forced to the nearest limit. Note that this is not the same as 
windowing because line angles may be affected by the forcing. 


ID # MNEMONIC FUNCTION 

128 SGMODE Set the value of GMODE 

129? RGMODE Read the current state of GMODE 

138 SDSPAT Set the dashed line pattern 

131 RDSPAT Read the current state of the dashed line pattern 

132 SMOVE Move the graphic cursor to a specified point 

133 SDRAW Draw a solid white line from graphic cursor to a point 

134 SVEC Draw a line from cursor to a point according to GMODE 

135 SDOT Plot a dot at a specified point according to GMODE 

136 SMOVER Move the graphic cursor relative to itself 

137 SDRAWR Draw a solid line from cursor to a point relative to itself 
138 SVECR Draw from cursor to a point relative to itself using GMODE 
137 SDOTR Plot a dot at a point relative to the cursor using GMODE 
148 SDRWCH Draw a single character at the graphiccursor position 

141 SISDOT Determine state of pixel at specified location 

142 SONGC Turn on the graphic crosshair cursor 

143 SOFFGC Turn off the graphic crosshair cursor 

144 RDGCR Read the position of the graphic cursor 

145 SGRIN Interactivly input a coordinate using the crosshair cursor 
146 SLTPEN Activate the light pen and return coordinates if a hit 

147 SINTLP Activate the light pen 


148 STSLP Test light pen and return coordinates if a hit 


3.4.1 SGMODE 128 = $3@ 

PURPOSE: Set the value of GMODE. 

ARGUMENTS PASSED: D@.B = New value of GMODE 

ARGUMENTS RETURNED: None 

DESCRIPTION: GMODE is a byte of flags Kept in 6582 memory which defines the type 


of line drawn by a number of the drawing SVCs. The table below 
lists the valid values for GMODE and their effect: 


$88 = Move 

$46 = Erase 

$58 = Erase dashed 

$86 = Draw 

$AG = Draw dashed 

$C@ = Flip 

$E6 = Flip dashed 

EXAMPLE: owas 

MOVE.B #$%A@,D@ 5; SET GMODE FOR A WHITE DASHED LINE 
TRAP 1 3; SVC 128 = SET GMODE 
DC.W 128 


This program segment will set GMODE for a white dashed line when drawing with 
SVEC or SVECR. When using SDOT or SDOTR, the dots plotted will be white. 


NOTES: 1. The setting of GMODE affects only those SVCs that say they are 
affected. 


2. The setting of GMODE is not preserved by SDRAY (133), SDRAWR (137), 
SONGC (142), SOFFGC (143), or SGRIN (145). 
3.4.2 RGMODE 129 = $81 
PURPOSE: Read the current setting of GMODE 
ARGUMENTS PASSED: None 
ARGUMENTS RETURNED: D@.B = Current value of GMODE 
DESCRIPTION: GMODE is a byte of flags Kept in 6502 memory which defines the type 


of line drawn by a number of the drawing SVCs. See SGMODE for a 
table of the valid values for GMODE and their effect. 


EXAMPLE : cece 
TRAP 1 SVC 129 = READ GMODE 
DC.W 129 
CMP.B #$88,D@ TEST IF GMODE SET FOR SOLID WHITE LINES 
BEQ ISNHITE BRANCH IF SO 


This program segment will read the value of GMODE and branch to ISWHITE if it is 
set for white solid lines. 


3.4.3 SDSPAT 138 = $82 

PURPOSE: Set the dashed line pattern. 

ARGUMENTS PASSED: D@.W = New contents of dash pattern register 
ARGUMENTS RETURNED: None 


DESCRIPTION: For certain values of GMODE ($68, $A@, and $E@), dashed lines are 
drawn. A 16 bit word Kept in 6582 memory determines the on-off 
pattern that makes up the dashes. As dashed lines are drawn, the 
16 bit pattern is circularly shifted left one bit far each pixel 
plotted. If a one is end-around-shifted, then the pixel is 
set/erased/flipped according to GMODE, otherwise, nothing is done 
at that pixel location. 


EXAMPLE : enee 
MOVE .W #$6F5F,D@ SET A PATTERN WITH ALTERNATE SHORT AND LONG 
TRAP 1 DASHES 
DC.W 138 


This program segment initializes the 16 bit dash pattern to alternate short and 
long dashes. 


NOTES: 1. The normal default dash pattern is $F@F@ which produces dashes 4 
pixels long separated by spaces 4 pixels long. 


2. If the dash pattern is set to zero and GMODE specifies a dashed line, 
nothing will be drawn. 


3.4.4  RDSPAT 131 = $83 

PURPOSE: Read the current state of the dash pattern. 

ARGUMENTS PASSED: None 

ARGUMENTS RETURNED: D@.W = Current state of dash pattern 

DESCRIPTION: The dash pattern is a 16 bit word Kept in 6562 memory that controls 
the drawing of dashed lines. RDSPAT is used for for saving this 


value while unrelated lines are drawn and then restoring it to 
continue drawing without a pattern discontinuity. 


EXAMPLE: sees 
TRAP i SVC 131 = READ DASH PATTERN 
DC.W 131 


MOVE.W D@,OLDPAT SAVE FOR USE LATER 


This program segment reads the dash pattern and saves it in OLDPAT for later 
use. 


NOTES: 1. The dash pattern value read by RDSPAT will not necessarily be the same 
value that was set by a prior SDSPAT SVC if dashed line drawing has 
taken place between setting and reading. Viewed circularly however, 
the pattern of one bits will be the same. 
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3.4.5 SMOVE i132 = $84 
PURPOSE: Move the graphic cursor to a specified point. 


ARGUMENTS PASSED: D@.W 
D1.W 


X coordinate of new location 
Y coordinate of new location 


ARGUMENTS RETURNED: None 


DESCRIPTION: SMOVE simply moves the graphic cursor to the point specified by the 
two arguments. The contents of the screen are not affected in any 
way. 


EXAMPLE : eee. 
MOVE .W #247,D8 MOVE THE GRAPHIC CURSOR TO X=247, Y=135 
MOVE.W #135,D1 


TRAP 1 SVC 132 = MOVE GRAPHIC CURSOR 
DC.W 132 


This program segment moves the graphic cursor to X=247? and Y=135. 


3.4.6 SDRAN 133 = $85 





PURPOSE: Draw a solid line from the graphic cursor to a specified point. 


ARGUMENTS PASSED: D@.W 
Di.W 


X coordinate of next endpoint 
Y coordinate of next endpoint 


ARGUMENTS RETURNED: None 


DESCRIPTION: SDRAW draws a soild white line from the current graphic cursor 
location to the point specified by the arguments. After the line 
is drawn, the graphic cursor is moved to the point specified 
by the arquments. 


EXAMPLE : eoes 
MOVE.W #389,D@ DRAW FROM CURSOR LOCATION TO X=387, Y=67 
MOVE.W #47,01 AND THEN MOVE CURSOR TO X=389, Y=67 
TRAP 1 SVC 133 = DRAW TO DESIGNATED POINT 
DC.W 133 


This program segment draws a solid white line from the present cursor location 
to X=387 Y=67? and then moves the cursor to X=389 Y=67. 


NOTES: 1. SDRAW will set GMODE to solid white but it will not affect the dash 
pattern, 
3.4.7 SVEC 134 = $86 


PURPOSE: Draw a line from the graphic cursor to a specified point according to 
GMODE. 


ARGUMENTS PASSED: Dé.W 
D1.W 


X coordinate of next endpoint 
Y coordinate of next endpoint 


ARGUMENTS RETURNED: None 
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DESCRIPTION: SVEC is the same as SDRAW except that the type of line drawn is 
influenced by GMODE and possibly the dash pattern. See SGMODE 
(128) for the effect of various GMODE values. 


EXAMPLE: woes 
MOVE.B #%48,D@ SET GMODE FOR ERASE 
TRAP 1 


DC.W SGMODE 

MOVE.W #389,D@ ERASE FROM CURSOR LOCATION TO X=389, Y=467 
MOVE.W #47,D1 AND THEN MOVE CURSOR TO X=389, Y=67 

TRAP i SVC 134 = DRAW TQ DESIGNATED POINT 

DC.W 134 ACCORDING TO GMODE 


This program segment will erases (draws black) from the present cursor location 
to X=387 Y=67 and then moves the cursor to X=389 Y=67. 


NOTES: 1. The dash pattern is affected only if GMODE is $68, $A@, or $E@. 


3.4.8 SDOT 135 = $387 
PURPOSE: Plot a dot at a specified point according to GMODE. 


ARGUMENTS PASSED: D@.W = X coordinate of dot 
Di.W = Y coordinate of dat 


ARGUMENTS RETURNED: None 


DESCRIPTION: SDOT will plot a single dot at the specified point according to the 
value of GMODE. After the dot is plotted, the cursor is moved to 
the specified point. The appearance of the dot depends on the 
setting of GMODE according to the following list: 


$46 = Move (no display effect) 
$40 = Erase (plot black dot) 
$86 = Draw (plot white dot) 
$C@ = Flip ‘(change dot from black to white or white to black) 
EXAMPLE: eave 
MOVE.B #$C@,D@ SET GMODE FOR FLIP 
TRAP 1 


DC.W SGMODE 

MOVE .W #132,D@ FLIP DOT AT X=132, Y=248 
MOVE.W #246,D1 

TRAP i SVC 135 = PLOT A DOT 
DC.W 135 


This program segment flips the black/white status of the dot at X=132, Y=24@ and 
then moves the cursor to X=132 Y=246. 
NOTES: 1. The dash pattern is not affected. 


2. GMODE values with bit 5 set ($68, $A@, and $£8) perform just as if 
bit 5 was not set. 


3.4.7?  SMOVER 136 = $88 
PURPOSE: Move the graphic cursor to a point relative to the graphic cursor. 


ARGUMENTS PASSED: D@.W 
D1i.W 


X displacement to new location 
Y displacement to new location 


ARGUMENTS RETURNED: None 


DESCRIPTION: SMOVER is similar to SMOVE except that the argument values are 
added to the present cursor position to determine its new position. 
The arguments therefore are 16 bit signed values. 


EXAMPLE : eens 
MOVE.W #30,D8 MOVE THE GRAPHIC CURSOR RIGHT 38 AND 
MOVE.W #-26,D1 DOWN 24 


TRAP 1 SVC 136 = MOVE GRAPHIC CURSOR RELATIVE 
DC.W 136 


This program segment will move the graphic cursor 3@ units to the right and 20 
units below its present position. 


3.4.18 SDRAWR 137 = $89 


PURPOSE: Draw a solid line from the graphic cursor to a point relative to the 
graphic cursor. 


ARGUMENTS PASSED: D@.W 
D1.W 


X displacement to next endpoint 
Y displacement to next endpoint 


ARGUMENTS RETURNED: None 


DESCRIPTION: SDRAWR is similar to SDRAW except that the argument values are 
added to the present cursor position to determine the line’s next 
endpoint. The arguments therefore are 16 bit signed values. 
After drawing, the cursor is updated to the new endpoint. 


EXAMPLE: eeee 
MOVE.W #-5,D@ DRAW A DIAGONAL LINE 1@ UNITS DOWN AND 5 UNITS 
MOVE.W #-16,D1 TO THE LEFT OF THE GRAPHIC CURSOR 
TRAP 1 SVC 137 = DRAW RELATIVE 
DC.W 137 


This program segment will draw a diagonal line extending 5 units to the left and 
1@ units below the present cursor position. After drawing, the cursor is moved 
J units to the left and 18 units below its original position. 


NOTES: 1. SDRAWR will set GMODE for solid white but will have no effect on the 
dash pattern. 
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3.4.11 SVECR 138 = $8A 


PURPOSE: Draw a line from the graphic cursor to a point relative to the graphic 
cursor according to GMODE. 


ARGUMENTS PASSED: D@.W 
D1i.W 


X displacement to next endpoint 
Y displacement to next endpoint 


ARGUMENTS RETURNED: None 


DESCRIPTION: SVECR is similar to SVEC except that the argument values are 
added to the present cursor pasition to determine the line’s next 
endpoint. The arguments therefore are 16 bit signed values. 
After drawing, the cursor is updated to the new endpoint. 


EXAMPLE : ceee 
MOVE.W #386,D@ DRAW A DIAGONAL LINE 158 UNITS DOWN AND 
MOVE.W #-158,D1 386 UNITS TO THE RIGHT OF THE GRAPHIC CURSOR 
TRAP | SVC 138 = DRAW RELATIVE ACCORDING TO GMODE 
DC.W 138 


This program segment will draw a diagonal line extending 388 units to the right 
and 156 units below the present cursor position. The type of line will be 
determined by the present setting of GMODE. 


NOTES: 1. The dash pattern is affected only if GMODE is $60, $A@, or $EQ@. 


3.4.12 SDOTR 139 = $8B 





PURPOSE: Plot a dot at a point relative to the graphic cursor according to 
GMODE. 


ARGUMENTS PASSED: D@.W 
D1.W 


X displacement to the dot 
Y displacement to the dot 


ARGUMENTS RETURNED: None 


DESCRIPTION: SDOTR is similar to SDOT except that the argument values are added 
to the present cursor position to determine the dot’s location. 
The arguments therefore are 146 bit signed values. After plotting, 
the cursor is updated to the dot’s position. 


EXAMPLE : eee 
MOVE .W #1,D8 PLOT A DOT JUST ABOVE THE THE DOT LAST PLOTTED 
CLR.W DI GMODE ASSUMED = $8@ = PLOT WHITE DOT 
TRAP 1 SVC 139 = PLOT DOT RELATIVE 
DC.W 139 


This program segment will plot a dot just above the dot last plotted. GMODE is 
assumed to be set for plotting white dots. After the dot is plotted, the cursor 
is moved up 1 pixel position. 
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3.4.13 


SDRWCH 148 = $8C 


PURPOSE: To draw a single character at the graphic cursor location. 


ARGUMENTS PASSED: D2.B = ASCII character to be drawn 


ARGUMENTS RETURNED: None 


DESCRIPTION: SDRWCH may be used to draw characters at any arbitrary location on 


EXAMPLE: 


the screen, The character cell used is 6 dots wide by 1@ dots high 
into which a character 5 dots wide by 7 dots high is written as 
illustrated below: 


a. or Oa ek a: OO: 60.4 Si er ye eciet Ole ter parce 
. « 0 « O.. Oe tones 8 oe, car UO! sae. sa cake 
Oe 600. 6 Oo Ds 2 OOO: oe 0: 20°60 o-4 
Oe sn 6 O80" 0: Oe. 5-0 oe O56 O- 0.40 
a o00 Os ee O60. 6, ee OO ve. Pe De 
Oi om carte. Orie Oe a 0 0. aOisg 60-8" OO Sice Se Ole 
Oe «e 30 OO. 0-00: 4 av ©-O0.04.6r70% 
character ee ee atl ee ee ee ° oO eo ee 
COOPGiNatesse=— Feo a Se ee ewe Ke ees 6 OOO hee cer ee Se 


The character’s coordinates refer to the lower left corner of the 6 
by 1@ cell. The character’s baseline is normally 2 dot rows above 
the bottom of the cell but lower case characters with descenders 
(9,J3,;P;9,y) will extend down to the bottom of the cell. The entire 
é by 18 character cell is cleared before the character is drawn so 
it may be desirable to draw characters first and then any graphics 
that might overlap portions of the cell. After the character is 
drawn, the X coordinate of the cursor is incremented by 6 in 
preparation for another character. Thus labels for charts and 
graphs may be easily drawn by repeated use of SDRWCH. The cursor’s 
X position must be between @ and 474 inclusive and its Y position 
must be between @ and 247 inclusive. If either is out of range, 
the character will not be drawn at all. Only printable ASCII 
character codes ($26-$7F) may be drawn, all other codes will not be 
drawn. 


MOVE.W #125,D@ MOVE TO X=125, Y=248 
MOVE .W #246,D1 

TRAP | 

DC.W SMOVE 

MOVE.B #’Q’,D2 DRAW THE LETTER "Q" THERE 
TRAP 1 

DC.W 148 


This program segment will draw the letter "Q" with its lower left corner at 
X=125 and Y=24@. After drawing, the cursor is moved 6 units right to X=131. 


NOTES: 


1. The cursor will not be returned and moved down when X reaches the 
right screen edge. 
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3.4.14 SISDOT 141 = $8D 
PURPOSE: To determine whether the pixel at the specified lacation is on or off. 


ARGUMENTS PASSED: D8.W 
D1.W 


X coordinate of pixel to be tested 
Y coordinate fo pixel to be tested 


ARGUMENTS RETURNED: CY 


1 if the pixel is set (white dot) 


DESCRIPTION: SISDOT is used to test the state of a particular pixel. After the 
pixel is tested, the graphic cursor is move to the position just 
tested and the carry flag is set equal to the dot’s status. 


EXAMPLE: eeee 


MOVE.W XLOC,D@ TEST THE PIXEL AT XLOC,YLOC 
MOVE.W YLOC,D1 


TRAP 1 SVC 141 = TEST A PIXEL 
DC.W 141 

BCC ISOFF SKIP IF THE PIXEL IS OFF 
eeee PIXEL IS ON 


This program segment looks at the pixel at XLOC,YLOC and branches to ISOFF if 
the pixel is off (black). 


3.49.15 SONGC 142 = $8E 
PURPOSE: To turn on the graphic crosshair cursor. 
ARGUMENTS: None 


DESCRIPTION: The graphic crosshair consists of a full screen height vertical 
line drawn at the X position of the cursor and a full screen width 
horizontal line drawn at the Y position. The crosshair is drawn in 
flip mode which means that parts of an image it covers will be 
restored when it is later turned off with the SOFFGC SVC. Flip 
mode also means that the cursor will show up regardless of the 
background color of the screen. 


EXAMPLE : ore 
MOVE.W XLOC,D@ MOVE TO XLOC,YLOC 
MOVE.W YLOC,D1 


TRAP 1 

DC.W SMOVE 

TRAP 1 

DC.W 142 SVC 142 = TURN ON THE CROSSHAIR CURSOR 


This program segment will display the crosshair cursor at XLOC,YLOC. 
NOTES: 1. If the crosshair is already on, SONGC will have no effect. 


2. SONGC will set GMODE for flip solid mode. 
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3.4.16  SOFFGC 143 = $8F 





PURPOSE: To turn the graphic crosshair cursor off. 

ARGUMENTS: None 

DESCRIPTION: SOFFGC turns the graphic cursor off that had been previously turned 
on by SONGC. For proper operation, the location of the graphic 
cursor must be the same as it was when the crosshair was turned on. 

EXAMPLE : eeee 

TRAP 1 

DC.W 143 SVC 143 = TURN THE CROSSHAIR CURSOR OFF 

This program segment will cease displaying the crosshair cursor. 


NOTES: 1. If the crosshair is already off, SONGC will have no effect. 


2. SQFFGC will set GMODE for flip sclid mode. 


3.4.17 RDGCSR 144 = $96 
PURPOSE: Read the position of the graphic cursor. 
ARGUMENTS PASSED: None 


ARGUMENTS RETURNED: D@.W 
Di.W 


X coordinate of the graphic cursor 
Y coordinate of the graphic cursor 


DESCRIPTION: RDGCSR may be used to determine the present graphic cursor position 
so that it may be saved, used in computations, etc. 


EXAMPLE: eae 
TRAP 1 READ THE CURRENT CURSOR POSITION 
DC.W 144 
MULU #3 ,D8 MULTIPLY THE X COORDINATE BY 3 
TRAP 1 MOVE TO THE NEW POSITION 


DC.W SMOVE 


This program segment will multiply the X coordinate of the graphic cursor by 3 
and move there. 
3.4.18  SGRIN 145 = $71 


PURPOSE: To allow user coordinate input by maneuvering a cursor with the 
Keyboard cursor control keys. 


ARGUMENTS PASSED: None 
ARGUMENTS RETURNED: D@.W 


D1.W 
D2.B 


X coordinate of final cursor position 
Y coordinate of final cursor position 
ASCII character entered by the operator 


DESCRIPTION: SGRIN activates a rapidly blinking full-screen crosshair cursor 
which can be maneuvered using the cursor keys on the Keyboard. It 
remains active until a non-cursor Key is struck. It then returns 
the coordinates and ASCII code of the Key struck. The shifted 
cursor control Keys move the cursor 5 times as fast as the 
unshifted cursor Keys. HOME is not considered to be a cursor Key 


by SGRIN. 
EXAMPLE: eens 
TRAP 1 DO THE SGRIN FUNCTION 
DC.W 145 
TRAP 1 MOVE TO THE COORDINATES RETURNED 
DC.W SMOVE 
CMP.B  #"5S" TEST IF "S" ENTERED 
BEQ Iss JUMP IF SO 


This program segment will display a crosshair cursor and allow the user to move 
it around the screen with the Keyboard cursor Keys. When a non-cursor Key is 
pressed, the graphic cursor will be moved to the last position of the crosshair. 
If the operator used the "S" Key to terminate the coordinate entry, the program 
will branch to ISS. 


NOTES: 1. The crosshair is drawn in flip mode so it will show up regardless of 
the background. 


2. The current graphic cursor position is not changed by SGRIN. 
3. There may be interference between SGRIN and the interrupting Keyboard 
if it is enabled. 
3.4.19  SLTPEN 146 = $92 
PURPOSE: Activate light pen for one frame and return coordinates of hit, if any. 
ARGUMENTS PASSED: None | 
ARGUMENTS RETURNED: D@.W = X coordinate of pen hit 


D1.W = Y coordinate of pen hit 
CY Set = the pen saw light and D@ and Di are valid 


DESCRIPTION: SLTPEN first waits for the end of the current screen scan and then 
begins checking for a light pen "hit" (response to light from the 
screen). If light is seen during the next screen scan, the X and Y 
coordinates of the beam position when the hit occured are placed in 
D@ and D1 and the carry flag is turned on. If no light is seen 
during the scan, the carry flag is turned off. The maximum amount 
of time before returning is 33 milliseconds when no light is 
detected. The time varies from less than 1 to a maximum of 32 
milliseconds when light is detected. The X and Y coordinates 
returned have resolution to the pixel level but a random variation 
up to + or - 2 coordinate units can be expected. 
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EXAMPLE : 


LPEN TRAP 1 SVC 146 = SLTPEN 
DC.W 146 
BCC LPEN WAIT FOR LIGHTPEN HIT 
TRAF i MOVE TO THE COORDINATES RETURNED 
DC.W SMOVE 
TRAP i FLIP THE DOT THERE (GMODE=$46) 


DC.W SDOT 


This program segment will wait indefinitely for a light pen hit. When the pen 
sees light, the graphic cursor will be moved to the light’s location and the 
pixel there flipped. 


NOTES: 1. The light pen will generally not respond to features less than 2 
Fixels wide horizontally. Thus single dots and vertical lines that 
are only one pixel wide will be invisible to the pen unless the screen 
brightness is very high. 


2. Light pens will, of course, only respond to those areas of the screen 
that are lit up. One method of obtaining light pen “hits" from the 
entire display is to use a white background. Any drawing that is 
required could be done as black-an-white. Also, on some monitors, it 
may be possible to adjust the black, or background, level up high 
enough to get "hits" over the entire display. 


3. D@ and Di are unchanged if the carry is returned clear (no hit). 


3.4.28 SINTLP 147 = $93 

PURPOSE: Wait for end of frame and then activate the light pen. 

ARGUMENTS: None 

DESCRIPTION: SINTLP performs the first half of the SLTPEN function. It 
essentially resets the light pen and allows it to look for light 


while the user program is doing something else. STSLP can be used 
later to determine if the pen saw light in the intervening period. 


EXAMPLE: eaee 
TRAP 1 ACTIVATE THE LIGHT PEN 
DC.W 147 


This program segment will activate the light pen at the end of the current 
screen sweep. 


NOTES: 1. The execution time of SINTLP ranges from near zero to 16.6 
milliseconds. 


2. Once the pen sees light after being activated by SINTLP, it will hold 


its coordinate information indefinitely until read by STSLP or is 
activated again by SINTLP or SLTPEN. 
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3.4.21 STSLP 148 = $94 
PURPOSE: Test for light pen hit and return coordinates if so. 
ARGUMENTS PASSED: None 


= X coordinate of hit 
D1.W = Y coordinate of hit 
t = hit registered and coordinates are valid 


DESCRIPTION: STSLP performs the second half of the SLTPEN function. It makes an 
immediate test of the light pen “hit" status and then returns with 
the carry set and coordinates in D@ and D1 if a hit had occured 
since it was last activated. If no light had been seen, carry is 
returned clear and D@ and Dj are unchanged. 


EXAMPLE: pr aiane 
TRAP 1 ACTIVATE THE LIGHT PEN 
DC.W SINTLP 
wate LOTSAMESS 
TRAP 1 TEST IF A LIGHT PEN HIT 
DC.W 148 
BCC HITT JUMP IF SO 


This program segment activates the light pen, performs some other functions, and 

then tests if a hit occured in the intervening time. A jump to HITT is taken if 

it did. 

NOTES: 1. Any amount of time may elapse between a light pen hit and when STSLP 
us used to test for the hit and compute the X and Y coordinates of the 
hit. 


2. D@ and Di are unchanged of the carry is returned clear. 


SPECIAL FUNCTION SVCS 


The special function SVCs provide a number of unique functions apart from 
CObOS interface, direct text 1/0, and graphics I/O. 


ID _# 


192 
193 
194 
195 
196 
197 
198 
199 
268 


3.5.1 READM 


MNEMONIC FUNCTION 
READM Read from any 6582 addressable memory location 
WRITEM Write into any 6502 addressable memory location 
BLKRD Copy a block of 6582 memory into 68888 memory 
BLKWRT Copy a block of 68886 memory into 6582 memory 
CALLM Call an arbitrary 6582 subroutine 


SETWDS8 Set the 68608 virtual display window parameters 
SETYP65 Set the 6582 display viewport parameters 


RFSH1 Copy the virtual display window into the viewport once 
RFSFSR Start continuous background window to viewport copying 
RFSHSP Stop continuous background display copying 
CPYDSP Reverse copy the display viewport into the window 
WAIT Wait for a specified time period before continuing 
CLKON Start a periodic interrupt to the 48608 
CLKOFF Stop the periodic interrupt 
CNTON Start a periodic increment of long word at $400268 
CNT OFF Stop the periodic increment 
KY BON Start the automatically scanned interrupting keyboard 
KYBOFF Stop the interrupting Keyboard 

192 = $C@ 


PURPOSE: To read the contents of any 6582 memory location. 


ARGUMENTS PASSED: A@.L = 6582 memory address (18 bits) 


ARGUMENTS RETURNED: D@.B = contents of that address 


DESCRIPTION: READM allows che user’s 68804 program to read the contents of any 


EXAMPLE: 


arbitrary 6562 memory or I/0 register location. It is particularly 
useful for direct control of 6562 1/0 devices and reading in-memory 
arguments returned by 6582 subroutines calied via CALLM (see 
section 3.5.5). 


muvtA.L #$BFD@,A@ SET ADDRESS OF PORT B OF PARALLEL I/0 


TRAP 1 READ THE PORT 
DC.W 192 
BTST #3,D@ TEST BIT 3 


This program segment reads location $BFD@ in the 6562’s address space which is 
port B of the standard MTU-13@ parallel interface. 


NOTES: 1. A full 18 bit address may be specified where bits 16 and 17 encode the 


bank number from @ to 3. Note that banks 2 and 3 will normally access 
Datamover memory from $886888 to $@@FFFF (bank 2) and $8@1688@ to 
SQ1FFFF (bank 3). 


2. 6582 display memory can be read between $1C@6@ and $iFBFF. 


3. READM requires approximately 411 microseconds to execute. 
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3.5.2 WRITEM 193 = $Ci 
PURPOSE: To write into any 6582 memory location. 


ARGUMENTS PASSED: A@.L 
D8.B 


6582 memory address (18 bits) 
Data byte to be written 


ARGUMENTS RETURNED: None 


DESCRIPTION: WRITEM allows the user’s 686@@ program to write into any arbitrary 
6582 memory or I/0 register location. It is particularly useful 
for direct control of 6502 1/0 devices and setting up in-memory 
arguments to 6582 subroutines called via CALLM (see section 3.5.5). 


EXAMPLE : sone 
MOVEA.L #$BFDC,A@ SET ADDRESS OF PCR OF PARALLEL 1/0 
TRAP 1 READ THE PORT 
DC.W READM 
BSET #6 ,D@ SET BIT @ = POSITIVE ACTIVE EDGE ON CAI 
TRAP 1 WRITE BACK THE NEW PCR CONTENTS 
DC.W 173 


This program segment first reads location $BFDC in the 6582’s address space 
which is the peripheral control register for the standard MTU-13@ parallel 
interface. It then sets bit @ in the data read and writes the updated value 
back into the same location. 


NOTES: 1. A full 18 bit address may be specified where bits 16 and 17 encode the 
bank number from @ to 3. Note that banks 2 and 3 will normally access 
Datamover memory from $800880 to $@@FFFF (bank 2) and $816888 to 
$Q1FFFF (bank 3). 


2. $5862 memory locations $E@68-$FFFF are normally write protected since 
they hold the CODOS operating system. If any of these must be written 
into, you must first execute an UNPROTECT command using SVCMON (13). 


3. WRITEM requires approximately 381 microseconds to execute. 


3.5.3 BLKRD 194 = $C2 
PURPOSE: To copy a block of 6582 memory into 68088 memory. 
ARGUMENTS PASSED: A@.L 


A1.L 
Dé.W 


6582 memory address (18 bits) 
68808 memory address 
Number of bytes to copy 


ARGUMENTS RETURNED: None 


DESCRIPTION: BLKRD allows the user’s 68808 program to quickly copy a block of 
6582 memory into the 68800’s address space. It is particularly 
useful for reading back arrays of data generated by 46582 
subroutines called via CALLM (see section 3.5.5). 


EXAMPLE : oe 
MOVEA.L #$A888,A8@ SET 6582 MEMORY ADDRESS = $AG08 
MOVEA.L #ARRYA2,A1 SET 68848 MEMORY ADDRESS = ARRYA2 
MOVE.W #2848,Dé6 SET BYTE COUNT 


TRAP 1 DO THE BLOCK READ 
DC.W 174 


This program segment reads a block of 2848 bytes from 6562 memory starting at 
$AGGG into 68888 memory starting at ARRYA2. 


NOTES: 1. A full 18 bit 6582 address may be specified where bits 16 and 17 
encode the bank number from @ to 3. Note that banks 2 and 3 will 


normally access Datamover memory from $806008 to $@@FFFF (bank 2) and 
$010808 to $@1FFFF (bank 3). 


2. The block source may not cross a bank boundary in the 6502’s address 
space. 


3. BLKRD is substantially faster than using READM in a loop. The copy 
speed is approximately 46uS per byte. 


3.5.4 BLKWRT 195 = $C3 


PURPOSE: To copy a block of 68806 memory into 6582 memory. 


ARGUMENTS PASSED: AG.L 
A1.L 
DE.W 


6582 memory address (18 bits) 
63868 memory address 
Number of bytes to copy 


ARGUMENTS RETURNED: None 


DESCRIPTION: BLKWRT allows the user’s 68088 program to quickly copy a block of 
688808 memory into the 6502’s address space. It is particularly 


useful for filling arrays of data for 6582 subroutines called via 
CALLM (see section 3.5.5). 


EXAMPLE : vee 
MOVEA.L #%9808,A8 SET 6582 MEMORY ADDRESS = $9808 
MOVEA.L #ARRYA1,A1 SET 68068 MEMORY ADDRESS = ARRYA1 
MOVE.W #28648,D8 SET BYTE COUNT 


TRAP 1 DO THE BLOCK WRITE 
DC.W 195 


This program segment writes a block of 2048 bytes from 68688 memory starting at 
ARRYA1 into 6582 memory starting at $9080. 


NOTES: 1. A full 18 bit 6582 address may be specified where bits 16 and 17 
encode the bank number from @ to 3. Note that banks 2 and 3 will 


normally access Datamover memory from $800086 to $@8FFFF (bank 2) and 
$816008 to $@1FFFF (bank 3). 


2. The block destination may not cross a bank boundary in the 6502’s 
address space. 


3. BLKWRT is substantially faster than using WRITEM in a loop. The copy 
speed is approximately 46uS per byte. 
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3.5.5 CALLM 196 = $C4 
PURPOSE: To call an arbitrary 6582 subroutine. 


ARGUMENTS PASSED: A@.W = Subroutine address in 6582 memory 


D@.B = Passed contents of 6582 A register 
D1.B = Passed contents of 6502 X register 
D2.B = Passed contents of 6502 Y register 
CY = Passed state of 6582 carry flag 


ARGUMENTS RETURNED: D@.B = Returned contents of 6562 A register 


D1.B = Returned contents of 6582 X register 
D2.B = Returned contents of 6502 Y register 
CY = Returned state of 6502 carry flag 


DESCRIPTION: CALLM allows the user’s 68806 program to call a 6582 machine 
lanquage subroutine with arguments passed and returned in the 6562 
machine registers. Additional arguments may be passed in memory 
using READM and WRITEM SVCs. 


EXAMPLE: eee 
MOVEA.W #OUTSMP,A@ PREPARE TO CALL OUTPUT SAMPLE SUBROUTINE 
MOVE.B (A3)+,D@ PASS SAMPLE VALUE IN 6562 A REGISTER 


MOVE.B #2,D1 PASS CHANNEL NUMBER IN 6582 X REGISTER 
TRAP 1 CALL THE SUBROUTINE 

DC .W 196 

BCS JUMP IF SUCCESSFUL SAMPLE OUTPUT 

cone OTHERWISE, ERROR 


This program segment calls a user written 6562 subroutine at OUTSMP with 
arguments in the 6582’s A and X registers. Upon return, it checks the carry 
flag which is set by the subroutine if its function was performed successfully. 


NOTES: 1. The 6582 subroutine is assumed to reside in bank @ therefore the 
subroutine address is only 16 bits. 


2. The subroutine must make only balanced use of the 65@2 stack and 
return with an RTS since the return path to DMXMON on the 6582 stack. 


3. The 6582 subroutine may use CODOS SVCs if desired. 
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The call/return overhead of CALLM is approximately 427uS. 


3.5.6 SETWD68 197 = $C5 
PURPOSE: To set the $8886 display window parameters. 


ARGUMENTS PASSED: A@.L Address of lower left corner of the window 


D@.B = Width of the window in bytes (1-68) 
Di.W = Height of the window in pixels (1-256) 
D2.W = Width of full image in bytes 


ARGUMENTS RETURNED: None 


DESCRIPTION: 


SETWD68 in conjunction with SETVP465 (198) is used to specify parameters for the 
transfer of bit mapped graphic information from 68088 memory to the 6562’s 
display memory. This allows a graphic image to be computed at high speed 
directly in 68888 memory and then copied to actual display memory in the 6502’s 
address space for display. 


Typically, the total image size in 68@8@ memory will be larger than the 
MTU-138’s screen. Consequently, just a portion of the image will be displayed. 
This portion is called the window and its size and location in the overal] 
image is what SETWD68 establishes. Note that the window may be specified to be 
smaller than the 48@ pixels (68 bytes) width and 256 pixels height of the 
MTU-13@ screen but may not be specified to be larger. See section 4.2 for a 
complete description of the virtual display. 


EXAMPLE : sees 


MOVEA.L #LLCORN,A@ SET TO DISPLAY LOWER LEFT CORNER OF IMAGE 
MOVE.B #166/8,D@ SPECIFY WIDTH OF 146@ PIXELS 


MOVE.W #1686,D1 SPECIFY HEIGHT 106 PIXELS 

MOVE.W #1824/8,D2 IMAGE WIDTH IS 1824 PIXELS 
TRAP i SET THE WINDOW PARAMETERS 

DC.W 197 


This program segment establishes a display window 168 pixels wide and 10@ pixels 
high located at the lower left corner of a virtual image in 68080 memory that is 
1824 pixels wide. 


NOTES: 1. The copy window routine does not need to Know the virtual image 
height. 


2. The virtual image may be anywhere in 68808 memory and as large as 
desired but a 64K boundary must only occur between rows of image 
bytes. 


3. Image organization in 688008 memory is the same as it is in 6582 
memory, that is, ascending memory addresses go from left to right and 


top to bottom. The bits in a byte appear on the display with the most 
significant bit at the left. 


4. The window specified should reside entirely inside the virtual image. 
3. There is no check for image overflow beyond the bottom of the 6502 


display screen. If the window is specified improperly, the character 
font table may be overwritten. 
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3.5.7 SETVP65 198 = $C6 
PURPOSE: To set the $562 display viewport parameters. 


ARGUMENTS PASSED: D@.W 
D1.W 


X coordinate of lower left corner of the viewport 
Y coordinate of lower left corner of the viewport 


ARGUMENTS RETURNED: None 
DESCRIPTION: 


SETVP68 in conjunction with SETWDé5 (197) is used to specify parameters for the 
transfer of bit mapped graphic information from 68008 memory to the $562’s 
display memory. This allows a graphic image to be computed at high speed 
directly in 686686 memory and then copied to actual display memory in the 6502’s 
address space for display. 


Typically, the total image size in $8888 memory will be larger than the 
MTU-138’s screen. Consequently, just a portion of the image will be displayed. 
This portion is called the window and its size and location in the overall 
image is what SETWD68 establishes. The location of this window on the physical 
display screen is what SETVP65 establishes and is called the viewport. The 
size of the viewport is the same as the size of the window specified by SETWDé8. 
The location of the viewport is specified by giving the X and Y coordinates of 
its lower left corner using standard MTU-138 display conventions. Note that if 
the X coordinate is not divisible by 8, the next lower value that is divisible 
by 8 is used. The viewport size and location should be such that no part of the 
viewport is outside the 488x256 display area of the screen. See section 4.2 for 
more information. 


EXAMPLE : sees 
MOVE.W  #96,D8 SPECIFY LEFT EDGE OF VIEWPORT AT 96 
MOVE.W #188,D1 SPECIFY BOTTOM EDGE OF VIEWPORT AT 188 
TRAP i SET THE VIEWPORT PARAMETERS 
DC.W 178 


This program segment establishes a viewport whose lower left corner is at X=96 
and Y=188. In conjunction with the example for SETWD68, the viewport will 
extend to X=?6+16@=256 for the right edge and Y=180+180=268 for the top edge. 
NOTES: 1. Remember that the X coordinate should be divisable of 8. The viewport 


width will always be a multiple of 8. The Y coordinate and Y size may 
be any integer. 


2. There is no check for image overflow beyond the top or the bottom of 
the 6582 display screen. If the window and viewport are specified 
improperly, the character font may be overwritten. 

3.5.8 RFSH1 199 = $C7 
PURPOSE: To copy the display window once into the display viewport. 
ARGUMENTS PASSED: None 


ARGUMENTS RETURNED: None 


DESCRIPTION: The RFSH1i SVC will physically copy 68868 memory into the 6502’s 
display memory. The source and destination addresses are 
determined from the window and viewport parameters previously 
established by SETWDé68 (197) and SETVPé5 (198). The copy routine 
used is highly efficient (and specialized) and will perform the 
copy many times faster than BLKWRT (195) would. 


EXAMPLE: mses 
(example for SETWD68) 
(example for SETVP65) 
TRAP 1 DO THE SCREEN COPY 
DC.W 199 


This program segment establishes the window and viewport parameters and then 
copies the window from 6868@ memory into the viewport in 6582 memory. 


NOTES: 1. The window and viewport parameters need not be reset after the copy 
unless they are to change. 


2. The copy time for the entire 488x256 display is approximately 258 
milliseconds. Times are proportionally shorter for smaller windows. 
The location and length/width ratio of the window have only a small 
effect on copy time. 


3.5.9 RFSHSR 208 = $C8 


PURPOSE: To start continuous background copying of the display window into the 
viewport. 


ARGUMENTS PASSED: None 
ARGUMENTS RETURNED: None 


DESCRIPTION: RFSHR allows the programmer to begin a “background task" in the 
6582 which continuously copies a display window in 68808 memory to 
a viewport in 6582 display memory. This action is performed 
continuously at maximum speed when the 46582 would otherwise be 
"idle" waiting for an 1/0 command from the 68808. RFSHR makes a 
copy of the parameters set by previous SETWD63 and SETVP65 SVCs 
when it is executed. Thus, these parameters may be changed after 
the background refresh is started so that an RFSH1 SVC can be 
executed for a single “foreground update" of a different portion of 
the screen without interfering with the ongoing background update. 


EXAMPLE: cece 
(example for SETWD68) 
Cexample for SETVP65) 
TRAP 1 START AUTOMATIC SCREEN COPY 
DC.W 2868 


This program segment establishes the window and viewport parameters and then 
initiates automatic copying of the window to the viewport until stopped by 
RFSHSP. 
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NOTES: 1. The automatic copy temporarily ceases while an SVC is being performed 
by the $658@Z. 


2. When automatic screen update is enabled, the 6582 checks for an SVC 
request after each scan line is copied. The latency time thus 
introduced is a maximum of 98@uS for a window 48@ wide (48 bytes) and 
decreases for narrower windows at the rate of i4uS per byte. 
Therefore, if a lot of short execution time SVCs (such as READM, 
WRITEM or byte-at-a-time I/0) are to be executed and speed is 
important, the automatic screen update should be turned off while they 
are executed. 


3. If the program is interrupted by a breakpoint or the INT Key, the 
display will not be refreshed while DMXMON is in console mode. 
Automatic refresh will however resume when DMXMON returns to execution 
mode unless a RESET command is entered. 


4. At the completion of each automatic refresh cycle, 68068 memory 
location $806141 will be set to a non-zero value. If location $806151 
is non-zero, the 68808 will also be interrupted at this time. See 
sections 4.2 and 4.4 for additional information. 


3.5.? RFSHSP 281 = $C9 


PURPOSE: Stop continuous background copying of the display window into the 
viewport at the end of the current frame. 


ARGUMENTS PASSED: None 
ARGUMENTS RETURNED: None 


DESCRIPTION: RFSHSP will stop automatic background display copying started by 
RFSHSR. It will wait until the copy currently in progress 
completes before stopping to prevent partiallly updated images on 
the screen. 


EXAMPLE: cae 
(example for SETWDé68) 
(example for SETVP65) 


TRAP 1 START AUTOMATIC SCREEN COPY 

DC.W RFSHSR 

TRAP 1 STOP AUTOMATIC SCREEN COPY AT END OF FRAME 
DC.W 261 


This program segment establishes the window and viewport parameters and then 
initiates automatic copying of the window to the viewport. Later, it stops the 
automatic copying at the end of a copy cycle. 


NOTES: 1. You may issue RFSHSP even if automatic copy had already been stopped 
or had never been started. 


3.5.11 CPYDSP 262 = $CA 


PURPOSE: To reverse copy the display viewport into the display window. 
ARGUMENTS PASSED: None 


ARGUMENTS RETURNED: None 


DESCRIPTION: The CPYDSP SVC will copy 6582 memory into $8688 memory. The source 
and destination addresses are determined from the window and 
viewport parameters previously established by SETWD68 (197) and 
SETVP65 (178). The copy routine used is highly efficient (and 


specialized) and will perform the copy many times faster than BLKRD 
(194) would. 


EXAMPLE : eee GENERATE IMAGE IN 6582 MEMORY 
sees ESTABLISH WINDOW AND VIEWPORT PARAMETERS 
TRAP 1 COPY DISPLAY INTO MY MEMORY FOR PROCESSING 
DC.W 282 


This program segment generates an image in 6582 display memory (perhaps by 
reading in a graphic image from disk), establishes the window and viewport 
parameters and then copies the image from 45802 memory into the window in 63068 
memory. 


NOTES: 1. The window and viewport parameters need not be reset after the copy 
unless they are to change. 


2. The copy time for the entire 4880x2546 display is approximately 258 
milliseconds. Times are proportionally shorter for smaller windows. 
The location and length/width ratio of the window have only a small 
effect on copy time. 


3.5.12 WAIT 263 = $CB 
PURPOSE: To wait for a specified time before continuing. 
ARGUMENTS PASSED: D@.W = Wait time in 6@ths of a second ("Jiffies"). 


ARGUMENTS RETURNED: None 


DESCRIPTION: WAIT allows a 68808 program to wait for a precise amount of time 
before continuing. Because of memory refresh and interference from 
the 6582 accessing Datamover memory, the execution time of a given 
68688 routine cannot be predicted precisely and therefore WAIT is 
useful if accuracy is desired. 


EXAMPLE: MOVE.W #18%68,D@ SET 18 SECOND WAIT 
TRAP i DO THE WAIT 
DC.W 283 


This program segment waits for 18 seconds and continues. The accuracy of the 
wait is unaffected by other activity in the system. 


NOTES: 1. 


Ze 


The maximum wait that may be specified is 65535/46@ seconds or about 18 
minutes. 


The timing reference used is the vertical retrace signal from the 
MTU-138 display. The actual period of this signal is 146.67888 
milliseconds + gj4,. This represents an error of +.8@7% with 

respect to 1/68 second (16.66666 milliseconds). .@1% is 8.6 seconds 
per day and .@7% is one minute per day. 


3.5.13 CLKON 264 = $CC 


PURPOSE: To start a periodic interrupt to the 68680. 


ARGUMENTS PASSED: D@.W = Time between interrupts in 1/é68ths of a second 


ARGUMENTS RETURNED: None 


DESCRIPTION: CLKON will start a periodic interrupt which a 68068 program may use 


EXAMPLE: 


to facilitate multi-tasking programming. At the end of each timing 
period, 68886 memory location $668143 will be set non-zero. If 
location $@86153 is non-zero, an actual 68804 interrupt will be 
generated. See section 4.1 for more information. 


MOVE.W #6,D8 SET 1@ PER SECOND INTERRUPT FREQUENCY 
TRAP i START THE INTERRUPTS 
DC.W 284 


This program segment starts a periodic interrupt every 1868 milliseconds (16 per 


second). 


NOTES: 1. 


2. 


The maximum period that may be specified is 65535/6@ seconds or about 
18 minutes. 


The timing reference used is the vertical retrace signal from the 
MTU-138 display. The actual period of this signal is 146.67800 
milliseconds *.@1%. This represents an error of +.07% with 

respect to 1/68 second (16.66666 milliseconds). .@1% is 8.6 seconds 
per day and .@7% is one minute per day. 


Timer interrupts will continue to occur even if the program is 
interrupted by a breakpoint or by pressing the INT Key or it exits 
normally. The RESET command will stop the timer. 


Leaving DMXMON with a BYE or CODOS command will stop the timer 
interrupts. 


The periodic interrupt clock is independent of the periodic counter 
described in section 3.5.15. 


Having the periodic interrupt enabled will affect the sound of 
Keyboard clicks slightly. 
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3.5.13 CLKOFF 2865 = 


$CD 


PURPOSE: To stop the periodic interrupt. 


ARGUMENTS PASSED: None 


ARGUMENTS RETURNED: None 


DESCRIPTION: CLKOFF will stop a periodic interrupt that had been started by 
It is good practice to stop the clock before the program 


CLKON. 
exits. 


EXAMPLE : TRAP 
DC.W 


1 
285 


STOP PERIODIC INTERRUPTS 


This program segment stops the periodic interrupt started earlier. 


NOTES: 1. You may use CLKOFF even if the clock had already been stopped or had 
never been started. 


3.5.15 CNTON 206 = $CE 


PURPOSE: To start periodic increment of a long word at $@00268. 


ARGUMENTS PASSED: D@.W = Time between increments in 1/é6a@ths of a second 


ARGUMENTS RETURNED: None 


DESCRIPTION: CLKON will start periodic incrementing of the long word at $800268. 
The time between increments may be specified to 1/6@ second 


resolution. 


This is useful for determining the execution time of 


program segments and for implementing software time-of-day clocks. 
Timing will remain accurate even if DMXMON enters console mode 
unless a RESET, BYE, or CODOS command is executed. 


EXAMPLE: CLR.L 
MOVE .W 
TRAP 
DC.W 


READC MOVE.L 


READW DBRN 


$268 
#1,D8 
1 

286 


$268 ,D0 
#126 
D1,READW 
$248 ,D0 
READC 


CLEAR THE COUNTER 
SET 6@ PER SECOND INCREMENT FREQUENCY 
START INCREMENTING THE COUNTER 


READ THE COUNTER 
WAIT $8 MICROSECONDS 


VERIFY IT 
TRY AGAIN IF NOT VERIFIED 


This program segment clears the counter at $080268 to zero and then sets a 6@Hz 
update rate. It later reads the counter and verifies its accuracy (see note 5). 
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NOTES: 1. 


The maximum update period that may be specified is 65535/48 seconds or 
about 18 minutes. Zero is interpreted as 65536/60. 


The timing reference used is the vertical retrace signal from the 
MTU-138 display. The actual period of this signal is 16.67808 
milliseconds *.41%. This represents an error of +.@7% with 

respect to 1/68 second (16.66466 milliseconds). .@1% is 8.6 seconds 
per day and .67% is one minute per day. 


The counter will continue to be incremented even if the program is 
interrupted by a breakpoint or by pressing the INT Key or it exits 
normally. The RESET command will stop the timer. 


» Leaving DMXMON with a BYE or CODOS command will stop the counter 


update. 


Update of the 4 counter bytes is performed sequentially by the 6582 
therefore there is a small chance that reading the counter will 
“catch” it partially updated. This possible error may be prevented by 
reading the counter, waiting at least 68 micraseconds with a timed 
loop, and reading the counter again. If the two values read are 
equal, then they are accurate. If not, repeat the procedure. (see the 
example above). 


Updating the counter is independent of the periodic interrupt. 


Having the counter enabled will affect the sound of Keyboard clicks 
slightly. 


It takes over 2 years for the clock word to “wrap around” at 6@ 
updates per second. 


3.5.15 CNTOFF 287 = $CF 


PURPOSE: To stop the periodic counter update. 


ARGUMENTS PASSED: None 


ARGUMENTS RETURNED: None 


DESCRIPTION: CNTOFF will stop a periodic counter increment that had been started 


EXAMPLE : 


by CNTON. 
TRAP 1 STOP PERIODIC COUNTER UPDATE 
DC.W 287 


This program segment stops the periodic counter update started earlier. 


NOTES: 1. 


You may use CNTOFF even if the counter had already been stopped or had 
never been started. 


3.5.17 KYBON 268 = $D@ 


PURPOSE: To start the automatically scanned interrupting keyboard. 


ARGUMENTS PASSED: None 


ARGUMENTS RETURNED: None 


DESCRIPTION: KYBON will start an automatic scan of the MTU-13@ keyboard so 


EXAMPLE: 


Keystrokes can be entered into a 6808@ program even if computation 
or other I/0 activity (such as disk access for an editor) is going 
on. While the automatic Keyboard scan is enabled, every Keystroke 
entered will be unconditionally stored in 468808 memory location 
$8086253 and location $680142 will be set non-zero. If location 
$808152 is non-zero, an actual 6800@ interrupt will then be 
generated. Typical usage would be with a 68808 interrupt service 
routine that reads the Keystrokes and places them in a programmed 
queue for action by the 688064 main program. See section 4.4 for 
more information. 


CLR.B $142 CLEAR KEYSTROKE ENTERED FLAG 
TRAP 1 START THE INTERRUPTING KEYBOARD 
DC.W 288 ‘ 


This program segment starts the interrupting Keyboard. 


NOTES: 1. The interrupting Keyboard employs an N-Key rollover scan algorithm 


instead of the 2-Key method the standard “wait on Keystroke" routines 
do. It also produces a uniform "click" sound from the keys even if 
the timer or counter has been enabled. These features are 
advantageous for high speed input of lots of text by experienced 
typists, therefore use of the interrupting Keyboard is recommended for 
$8068 based editors and word processors. 


In general, the interrupting Keyboard will not drop keystrokes even if 
several Keys are hit all at once. The minimum time between Keystrokes 
passed to the 68888 is 16 milliseconds however. If necessary, the 
Keyboard routine will automatically queue Keystrokes that are 
recognized more rapidly than this. 


» The interrupting Keyboard does NOT flash or manipulate the cursor on 


the display or echo characters to the screen. These functions must be 
done by the 68868 program through the text display SVCs (see section 
3.3 and 4.5). 


» A regular Keyboard input SVC can be issued even if the interrupting 


keyboard is enabled. Keystrokes will be returned both by the SVC and 
by the interrupting Keyboard routine. This condition can be 
recognized because each Key pressed will produce two clicks. 


If the program is interrupted by a breakpoint or by pressing the INT 
Key, the interrupting Keyboard will continue to enter Keystrokes into 
the 68686 and interrupt it. This condition can be recognized because 
each Key pressed will produce two clicks, one from the standard 
Keyboard routine and one from the interrupting routine. Although 
disconcerting to hear, each routine will still function normally. The 
RESET command will stop the interrupting keyboard. 
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3.5.17 KYBOFF 289 = $Di 

PURPOSE: To stop the interrupting Keyboard. 

ARGUMENTS PASSED: None 

ARGUMENTS RETURNED: None 

DESCRIPTION: KYBOFF will stop the interrupting Keyboard that had been started by 
KYBON. It is good practice to stop the interrupting keyboard 


before the program exits. 


EXAMPLE: TRAP 1 STOP INTERRUPTING KEYBOARD 
DC.W 289 


This program segment stops the interrupting Keyboard started earlier. 


NOTES: 1. You may use KYBOFF even if the keyboard had already been stopped or 
had never been started. 
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ADVENICED PROGRGMMING TECHNIQUES 





DMXMON has a number of advanced features that allow usage of sophisticated 
programming techniques by advanced programmers. They are however implemented in 
such a manner that inherently simple programming tasks are not complicated. 
These advanced features include timing functions, automatic updating of the 
MTU-13@ display from image data in 68486 memory, overlapped computation and 1/0, 
and the handling of interrupts. Each of these topics is discussed in detail in 
the following sections. 
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USING THE TIMING FUNCTIONS 





In order to satisfy a variety of timing requirements in 68880 programs, 3 
different timing functions are offered. Each operates independently so a given 
program could use one, two, or all three simultaneously without interference. 
All of the timing functions use the 6@Hz signal from the MTU-13@ display 
generator as the basic timing signal. Timing resolution is therefore 1/68 
second and timing accuracy is unaffected by other activity in the system. The 
timing functions may be used for applications ranging from simple waits and 
time-of-day clocks, to complex scheduling in multi-tasking operating systems 
built on top of DMXMON. 


4.1.1 The WAIT SVC 


The simplest timing function is that offered by the WAIT SVC which is SVC 
#203. With this SVC you simply specify the wait time in units of 1/68 second 
and the SVC processor will wait that amount of time before returning control to 
the user’s program. This is a "wait once" function because each time a wait is 
required, the duration must be specified and the WAIT SVC executed. Additional 
information on WAIT may be found in the writeup on WAIT in section 3.5.12. 


4.1.2 The Autcincrement Counter 





Another Kind of timing function is offered by the automatically incremented 
counter. The counter consists of a long word at 68868 memory location $806268. 
When the autoincrement counter is enabled, this long word will be periodically 
incremented at the specified interval. An SVC is provided to start the counter 
CCNTOND and to stop the counter (CNTOFF). The count interval, in 1/é@ths of a 
second, is specified when the counter is started by CNTON. The user program may 
read and set the counter at any time. 


A typical use for the autoincrement counter is as a time-of-day clock (in 
systems without a MultI/0 board). The 68808 application program would typically 
ask the user for the time and date and then store a 32 bit number representing 
that time into the counter at $8@80268. The counter would then be started with a 
CNTON SVC and the update rate would be specified as 1 second (6@). The contents 
of the counter then would reflect the current time and date until the system was 
powered down or DMXMON was exited with a BYE or CODOS command. Note that a 32 
bit counter incremented at a one second rate will run for 136 years before 
overflowing. 


The user program may read or set the counter at any time with a simple MOVE 
or other instruction. However, since the counter is incremented one byte at a 
time by the 6582, there is a small chance that the 6582 will be incrementing the 
counter at the same time and thus cause an erroneous reading or setting. The 
simplest method of avoiding this possibility when reading the counter is to read 
it twice with a timed loop delay of 6@uS between readings and compare the 
readings. If they are equal, the value is accurate. If they differ, it should 
be read again until two successive readings are identical. The easiest method 
of insuring accurate writing is to immediately preceed the write operation with 
a WAIT SVC that specifies a 1/68 second wait. Since the counter update will 
always immediately preceed the wait expiration, there will be no chance of an 
error. 


4.1.3 Periodic Interrupt Clock 


The third timing technique is a periodic interrupt clock. With this 
technique, the 68088 can be interrupted at a set interval to perform functions 
such as task swapping and real-time control. When the periodic interrupt clock 
is started with the CLKON SVC, an interval is specified and an internal clock is 
set for that interval. Control is immediately returned to the user program 
after the clock is started. When the internal clock expires, it is immediately 
restarted (for the next interval). Simultaneously, 68868 memory location 
$000143 is unconditionally set non-zero to indicate that the clock has timed out 
and been restarted. If location $@00153 is non-zero, the 63008 will also be 
interrupted. Thus a program can operate the periodic interrupt clock on a 
polled basis (wait in a loop for $143 to go non-zero) or a vectored interrupt 
basis. The handling of interrupts by DMXMON is described in section 4.4. 
Typically, after the user program has recognized the clock timeout, it would 
clear lacation $@08143 in preparation for the next timeout. Since the clock is 
automatically restarted, the interrupt frequency is not affected by the 
interrupt response time of the program. 


The periodic interrupt may be stopped by executing a CLKOFF SVC. This SVC 
stops the clock immediately so if only a single interrupt after a timeout is 
desired, you would just turn the clock off in the clock interrupt service 
routine. See section 4.4 for additional information on how DMXMON handles 
interrupts and links to user service routines. 


4.2 USING THE 68688 MEMORY RESIDENT VIRTUAL DISPLAY 





One of the most valuable features of the MTU-138’s 6582 CPU board is the 15K 
block of memory set aside exclusively for a 48@ wide by 256 high bit-mapped 
graphic display. Numerous SVCs in DMXMON support this display with a complete 
array of character and graphic drawing functions. All of these SVCs are 
actually executed by the 6582 microprocessor since it has direct access to the 
display memory. 


However, DMXMON also has support for a virtual display memory that is 
directly addressable by the 68808. This allows the 68088’s high potential 
drawing speed to be utilized in the generation of very complex graphic images. 
To see the contents of the virtual display memory, it is simply copied into the 
real display memory using an SVC, a process that takes less than a quarter 
second. The most significant feature of the virtual display memory however is 
that its size (width and height in pixels) can be specified by the programmer. 
In particular, the size can be much larger than the 480x256 size of the real 
display memory! In fact, the only real limitation is the memory capacity of the 
Datamover but even just half of the standard capacity (128K) can give a 
1624x1824 virtual image size. 
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Of course if the virtual display memory is larger than the real display 
memory, only a portion of it may be viewed on the screen at once. In addition, 
the portion to be viewed may be smaller than the 486x256 screen in order to 
leave space for other uses, such as message display. SVCs are available to 
communicate the overall virtual display size, the location and size of that 
portion that is to be displayed, and where on the physical screen it is to be 
displayed. The drawing below will serve to illustrate the concepts and 
terminology that will be used in the following discussion. 


VIRTUAL SCREEN 
SCREEN WIDTH 
MTU-130 SCREEN 
VIEWPORT 
Liccarion 
6502 RAM 





The portion of 68886 memory that is used for the virtual display is called 
the virtual screen. The virtual screen’s size is characterized solely by 
its width in bytes. The width in bytes is simply the width in pixels divided 
by 8. The virtual display SVCs can deduce the virtual display’s height and 
location in 68884 memory from other information described below. 


The portion of the virtual screen that will be visible on the real screen is 
called the window. The window is characterized by giving its width in 
bytes, its height in pixels and the 63068 memory address of its lower left 
corner. The window must not be specified to be larger than the MTU-130’s real 
display which is 6@ bytes wide and 254 pixels high. It is also the programmer’s 
responsibility to ensure that the window stays inside the virtual screen; 
otherwise random data outside the virtual screen will show up on the real 
screen. 


The portion of the real screen that will be used to display the window is 
called the viewport. The viewport is characterized simply by giving the X and 
Y coordinates of its lower left corner. The viewport’s width and height is 
equal to the window’s width and height. Note that the X coordinate given for 
the viewport location should be a multiple of 8. If it is not, it is rounded 
down to the next lower value that is a multiple of 8. 


Before the window can be correctly copied into the viewport to be seen, all 
of the characteristics described above must be “Known" to the screen copy 
routines. Two SVCs are used to communicate this information. SETWD68 is the 
SVC used to establish information about the window. The arguments of SETWDé8 
are: 
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1. The width of the virtual screen in bytes 

2. The width of the window in bytes 

3. The height of the window 

4. The 68866 memory address of the lower left corner of the window 


SETVP65 is the SVC used to establish information about the viewport. The 
arguments of SETVPS5 are: 


1. The X coordinate of the lower left corner of the viewport 
2. The Y coordinate of the lower left corner of the viewport 


Qnce this information is established, the screen copy SVCs can be used as many 
times as desired until one of the parameters needs to be changed. Note that 
there is no error checking of the parameters specified. You need to be 
particularly careful to prevent the viewport from going beyond the MTU-130’s 
screen boundaries. If it does, bank 1 memory below the screen and possibly a 
little above can be wiped out. 


The simplest virtual display SVC is RFSH1. When this SVC is used, the 
windcw will be copied into the viewport once and the SVC will be finished. 
Nothing on the screen outside the viewport will be disturbed but everything 
inside will be replaced with the window contents. RFSH1 requires approximately 
1/4 second for a full screen transfer (68 bytes wide and 256 pixels high) and 
proportionally less for smaller windows. 


In cases where the virtual display is changing, one might want the real 
screen to be continuously updated from the virtual screen, preferably as an 
automatic background operation. This function is in fact available and can be 
started by executing the RFSHSR SVC. When RFSHSR is executed, a duplicate is 
made of all of the window and viewport parameters that were established by 
SETHDS8 and SETVP65. After the duplicate is made, the RFSHSR SVC is considered 
complete. From then on the window is repeatedly copied into the viewport until 
an RFSHSP SVC is executed which stops the copying. Copying is actually done by 
the 6582 CPU and only steals about 5% of the available memory cycles from the 
68088. Copying is temporarily suspended when another SVC is being executed but 
then restarts automatically when it is finished. When copying is stopped with 
RFSHSP, the SVC processor ensures that it will be stopped at the end of a 
complete copy cycle. 


Since the automatic background copy routine has its own copy of the window 
and viewport parameters, these parameters may be changed after the automatic 
refresh has been started. Then RFSH1 SVCs can used to update a different 
viewport on the 138’s screen on demand even while automatic refresh is taking 
place. This capability can be used to tremendous advantage in split-screen and 
multiple viewport applications. 


There is also an SVC, CPYDSP, that does a reverse copy from the viewport 
into the window. It is useful where an image created by the 6582 (such as 
loading an image file from disk) needs to be transferred to the virtual screen 
for direct manipulation by the 68688. Note that all of these screen copying 
functions could be performed by the BLKRD and BLKWRT memory transfer SVCS but 
these are many times slower than the highly optimized routines just described. 
Also note that DMXMON does not provide support for drawing graphics and 
characters into the virtual screen in 6880@ memory. Such routines must be 
provided by a separate program. 
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4.3 OVERLAPPING COMPUTATION AND 1/0 





Frequently the performance of a program can be substantially improved by 
overlapping computation and I/0 operations. The technique is particularly 
effective when overall execution time is evenly split between waiting on I/O and 
computation and the I[/0 is relatively simple such as sequentially reading 
through a long file. In such cases, overlapping can nearly double the speed of 
a program. 


The internal processing of SVCs by DMXMON actually consists of three phases. 
In the first phase, the arguments of the SVC are transferred to the $562 by the 
68888 portion of DMXMON and the I/O operation is started. In the second phase, 
68886 DMXMON waits for an indication from the 6562 that the operation is 
complete. The third phase consists of transferring the return arguments back 
and returning to the user program that issued the SVC. Obviously, during the 
second phase, which can range from a few microseconds to several seconds 
depending on the operation, the 688686 is simply waiting when it could possibly 
be doing serious computing. 


When a regular TRAP 1 SVC is executed, the start-wait-complete sequence just 
described is executed. When an SVC using a TRAP 2 instruction is executed 
however, the SVC processor will just execute phase 1 and then immediately return 
to the calling program with all of the registers intact. The calling program 
can then perform computation or whatever up until it needs the results of the 
1/0 operation that had been started. To complete phases 2 and 3 of the SVC, a 
TRAP 3 instruction WITHOUT an ID number is executed. If the I/0 operation has 
indeed completed, the return arguments will be immediately loaded into the 
registers and a return made. If the I/O operation has not yet completed, the 
TRAP 3 processor will wait for it to complete, load the return arguments, and 
return. Thus the sequence: TRAP 2 <svc id>, TRAP 3 is exactly equivalent to 
TRAP 1 <svc id>. 


For highly efficient overlap of computation and 1/0, arrangements can be 
made to have the user program interrupted when a currently pending SVC is ready 
to be completed. When the 6582 is finished with the 1/0 operation, it will 
unconditionally set the byte at $86014@ non-zero. If the byte at $660158 is 
non-zero, the user program will be interrupted and the user’s service routine 
will be entered through the vector at $6861080. The interrupt service routine 
can then issue the TRAP 3 to complete the currently pending SVC and perhaps even 
start another. See section 4.4 for additional information on DMXMON interrupts. 


The primary restriction in using "split SVCs" is that only one SVC 
operation can be in progress at any one time. Thus every SVC that is started 
with a TRAP 2 must be completed with a TRAP 3 before another SVC may be started 
with either another TRAP 2 or a TRAP 1. Violation of this restriction wil] 
cause DMXMON to halt the user program and print an error message. 


4.4 INTERRUPTS 


For programs that need them and programmers that can use them, DMXMON has 
support for handling interrupts. This support is provided without sacrificing 
programming ease in non-interrupt applications. Since the Datamover is really a 
slave processor with all of its I/0 handled by the 6582, there are no hardware 
1/0 interrupts as such. The 6502 portion of DMXMON however can generate 
interrupts under certain conditions and the 688@@ portion of DMXMON can direct 
these interrupts to service routines in the user program. Interrupts generated 
internally by the 68648 (such as divison by zero) are passed directly to the 
user’s service routine (if one is provided) or to DMXMON’s error processor which 
will print complete diagnostic information. 
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4.4.1 68668 Hardware Interrupts 





The MCS68888 microprocessor has perhaps more internally generated interrupt 
sources than any other microprocessor. Most of these refer to error conditions 
such as zero divide, addressing error, illegal instruction, etc. When DMXMON is 
started or a RESET command is entered, all of these interrupt vectors are set to 
point to error message routines. Thus if a divison by zero is attempted and its 
vector has not been changed, DMXMON will print: "NO USER VECTOR FOR ZERO DIVIDE" 
and then print the register contents as an aid in locating the error. If the 
programmer wishes to handle such interrupts himself, the corresponding vector 
should be changed to point to the programmer’s service routine instead. 


Because of the Datamover’s internal design, many of the 68800’s interrupts 
cannot occur. The table below lists all of the interrupts that can occur, their 
vector addresses, and what the vector points to by default: 





VECTOR CAUSE POINTS TO 
868804 RESET DMXMON Initialization routine 
86888C Address error XXXADDRESS ERRORXXX 
000818 Illegal instruction XXXILLEGAL INSTRUCTIONX¥x 
888814 Zero divide X¥XXNO USER VECTOR FOR ZERO DIVIDEX%X 
866818 CHK instruction XX¥XNO USER VECTOR FOR CHK INSTRUCTIONXXX 
868B1C TRAPYV instruction XXXNO USER VECTOR FOR TRAPV INSTRUCT IONXXX 
868826 Privilege violation XXXPRIVILEGE VIOLATIONXXX 
688824 Trace XXXNO USER VECTOR FOR TRACE INTERRUPTXXX 
884828 Line 1818 emulator XXXNO USER VECTOR FOR EMULATOR OP CODES*XxX 
68682C Line 1111 emulator X£XNO USER VECTOR FOR EMULATOR OP CODESXXX 
800878 Level 4 autovector DMXMON maskable interrupt service routine 
866B7C Level 7? autovector DMXMON console interrupt service routine 
860886 TRAP @ instruction DMXMON breakpoint processor 
880834 TRAP 1 instruction DMXMON start-wait-complete SVC processor 
6868893 TRAP 2 instruction DMXMON start only SVC processor 
88688C TRAP 3 instruction DMXMON wait-complete SVC processor 
868098 

- TRAP 4-15 X*¥XNO USER VECTOR FOR TRAP INSTRUCTIONXXX 
@888BF 


Those vectors that point to error messages can be freely changed by the user 
program to point to the user’s error processor. The vectors that point to 
DMXMON functional routines should not be changed unless there is an overwhelming 
reason to do so. The vectors for interrupts that cannot occur may either be 
unused or may be used by DMXMON for system storage. See the detailed memory map 
in section 5.1 for a complete listing of memory usage by DMXMON. 


4.4.2 DMXMON GENERATED INTERRUPTS 

The interrupts most likely to be of interest to the programmer are those 
generated by DMXMON itself. Each of these interrupts has a request flag, an 
enable flag, and a vector, all stored in low 68006 memory. After reset or on 
startup, the request flags and enable flags (one byte each) are zeroed and the 
vectors are set to point to an error message. When a condition that can cause a 
DMXMON interrupt occurs, the corresponding request flag is unconditionally set 
to $FF. If the corresponding enable flag is zero, thats all that happens. If 
the enable flag is non-zero, then an actual interrupt occurs and the 
corresponding vector points to the user’s service routine. The user’s service 
routine is expected perform its function and then return with an RTS instruction 
(not an RTE!). DMXMON’s interrupt dispatcher then zeroes the request flag to 
indicate that the interrupt has been serviced. 
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Currently, four DMXMON interrupts are defined and there is space for 12 
more. The table below summarizes these: 


REG BYTE ENAB BYTE VECTOR DESCRIPTION 

486148 886158 886188 Currently pending SVC has completed 
066141 @64151 686184 Automatic screen refresh cycle complete 
688142 888152 886188 Interrupting Keyboard character available 
086143 886153 B8418C Timer interrupt 


886144 666154 866116 


Unassigned. 
608 14F 6@@15F 88613F 


When more than 1 request flag is active, the one corresponding to the lowest 
address in the table above is checked and acted upon first. Technically, all of 


these interrupts are on the same level however so the service routine for one 
cannot be itself interrupted. 


4.5 THE INTERRUPTING KEYBOARD 


To facilitate the writing of “human engineered” highly interactive programs 
such as word processors, DMXMON has provisions for an interrupting "background" 
keyboard. With the normal DMXMON (and CODOQS) Keyboard routines, when the 
program needs keyboard input, it calls a Keyboard routine (or executes a 
keyboard SVC) which waits for the operator to press a key. When a Key is 
pressed, the Keyboard routine returns and the calling program processes the 
character. After the character is processed, the keyboard routine is called 
again for the next character. This process is represented in the flowchart 
drawing below: 






INITIALIZE 


The usual problem with this simple arrangement is that the Keyboard is 
unresponsive while the character is being processed. Normally this is no 
problem when the processing is relatively simple and only main memory is 
involved because the processing time is only a few milliseconds. There is also 
no problem when program communications with the user is of the 
“command-response" type because the time consuming operations (computation or 
accessing the disk) only occur when the operator expects to wait after the 
command is “entered” by pressing Return. 
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In a free format editing type of program, however, time consuming operations 
such as moving memory around, scrolling or updating the screen, or accessing 
the disk may occur at any time. If the operator is busily typing away at one of 
these times, Keystrokes will not be seen by the program and consequently will be 
lost. Use of the interrupting Keyboard facilities of DMXMOQN is a solutian to 
this problem. 


Naturally, program organization is somewhat different (and slightly more 
complex) when the interrupting keyboard is used. Typical organization is as two 
"tasks" that are linked together by a first-in-first-out queue as in the diagram 
below: 





Normally, the main program on the right is executing. Assuming that the 
interrupting Keyboard is enabled, when a Keystroke is entered, the routine at 
the left CINTRUPT) immediately gains control through the Keyboard interrupt 
vector arbitrated by DMXMON. This routine reads the ASCII character just 
entered and stores it in the queve. It then does a Return from Subroutine 
(NOT Return from Exception!) to indicate that it is finished. The DMXMON 
interrupt dispatcher clears the interrupt request and then returns control to 
the main program on the right at the point of interruption. 


The main program is basically organized just like the simple “wait on 
keystroke" version described earlier. The only difference is that the block 
marked "WAIT FOR CHARACTER" is replaced with 2 blocks that look at the queve 
instead. If the queue is empty, it loops around and looks again. If there is a 
character (or several characters) in the queue, it is withdrawn and acted upon. 
After the character is processed, the queve test loop is re-entered. Regardless 
of how long the "Process Character" block takes, the interrupt service routine 
will continue to gain control on every Keystroke entered so that none are lost. 
If the process block takes a long time, it is entirely possible for several 
Keystrokes to be "backed up" in the queue. They all will be processed as 
quickly as possible when the time consuming operation is complete. 


Note that this arrangement is much more flexible than the “intelligent 
keyboards" offered on some computers because in some cases strict queve 
operation may be undesirable. For example, an error condition may arise as the 
result of processing a character. At that point, the queve probably should be 
cleared of any characters that may have backed up because they may represent an 
inappropriate response to the error condition. Another example would be in an 
editing program where some keystrokes may have a destructive effect or depend 
for their effectiveness on hand-eye coordination of the operator (such as moving 
the cursor). Such characters probably should not be queued so that the display 
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goes not "fall behind" what is being entered. With the interrupting keyboard 


a 
itral of the programmer. A separate intelligent Keyboard may not be able to 
To with such situations or may be inflexible in handling them. 


Whereas the regular "wait for Keystroke" SVCs will display a flashing cursor 
on the screen while waiting and some even display the characters entered, the 
interrupting keyboard acts independently of anything else and therefore does not 
interact with the display in any way. This means that the user program is 
responsible for flashing the cursor and displaying the character. Fortunately, 
several SVCs are provided to make this task a simple one. 


@ flowchart below illustrates the typical programming necessary to display 
a ¢lashing cursor and echo keystrokes to the screen when the interrupting 
ard is used: 











PROCESS 
CHARACTER 


aily, the flowchart is the same as before. The interrupt service 
routine is exactly the same so it is not shown. Immediately before the loop 
that waits for a character to appear in the queue, the text cursor is turned on 


With an ONTCR SVC, Also, the "flash timer" is started with a CLKON SVC. While 
in the wait-on-queve loop, the timer expired interrupt request flag at $800143 
is tected as well as the queue empty condition (actual interrupts from the timer 
are not enabled). When the timer expires, the cursor is flipped with a FLPTCR 
SVC, The cursor continues to be flipped at a rate determined by the timeout 
value set earlier until a character is found in the queue. Before the character 
is processec, the text cursor must be turned off, otherwise the reverse video 
square will remain on the screen if character processing results in cursor 
movement. The character is then processed and the program loops back to get the 
next character. For absolute maximum efficiency you may want to check the queve 
once before the cursor is turned on to avoid the cursor overhead when there is a 
backup of characters in the queue. 


The example program in section 6.3 illustrates how the interrupting keyboard 
and cursor control SVCs can be used. The program object file is called 
EXAMPLE2.6 and can be run by starting DMXMON and then entering that file name. 
The application is just simply typing text onto the screen. To escape the 
program and return to DMXMON, enter a ctri/Z. You can check the queueing 
action by entering a bunch of cursor-downs (which cause time consuming scrolls 
if the cursor is at the bottom of the screen) followed by some text. 


90 


3 


APPENDIX 


5.1 MEMORY MAPS 


321.1 MEMORY USED BY 6582 DMXMON 





The table below gives the locations in 65@2 memory that are used by DMXMON. 
Locations not listed may be freely used by 6502 utilities and other programs 
executed through DMXMON or by user written subroutines called from a 48000 
program. 


ADDRESS RANGE USED FOR 
8655 - BAF Zero page variable storage 
8768 - @BAFF General variable storage 
@BBB - 3941 Code for 6582 portion of DMXMON 
3942 - 4941 Copy of code for 68688 portion of DMXMON 
1FC@B -1FC38 Virtual screen copy routines (Bank 1) 
2.1.2 MEMORY USED BY 68888 DMXMON 


The table below gives the locations in 68808 memory that are used by DMXMON. 
Locations listed as -unused- may be utilized by user programs. It is 
recommended however that user programs confine their memory usage to locations 
above $681668. Note that the RESET command will restore all 68068 memory from 
$606008 to $@68FFF to the state it was immediately before DMXMON was entered 
from CODOS. 


ADDRESS RANGE USED FOR 

G08008 - 860803 Initial stack pointer after Reset 

668884 - 8668067 Initial program counter after Reset 

@806G3 - B8B66B Hardware bus error vector (should not be possible) 
68GG6C - BOBGGF Address error vector 

680018 - 668013 Illegal instruction error vector 

668014 - 648017 Zero divide error vector 

680813 - @00801B Check against bounds vector 

G68G1C - B4BG1F TRAPY instruction vector 

6G8628 - 8668823 Privilege violation vector 

668824 - 868027 Trace interrupt vector 

6868023 - 668828 1818 emulator vector 

6686820 - 86882F 1111 emulator vector 

666838 - 86805F -unused- 

608068 - 868863 Spurious interrupt vector (should not be possible? 
6680064 - B0B06F Autovectors 1-3 (should not be possible) 

666078 - 6862873 Level 4 autovector to DMXMON interrupt dispatcher 
688874 - 68867B Autovectors 5-6 (should not be possible) 

68807C - 86807F Level 7 autovector to DMXMON console interrupt handler 
686888 - 868883 TRAP @ vector to DMXMON breakpoint processor 
686884 - 88868F TRAP 1-3 vectors to DMXMON SVC processor 

668698 - 8886BF TRAP 4-15 vectors 

@688C@ - @B06FF -unused- 

668168 - 688183 SVC operation complete interrupt vector 

688184 - 860187 Automatic screen update completed interrupt vector 
686168 - 88018B Keyboard interrupt vector 

@6818C - 86814F Clock interrupt vector 


668118 - @8813F Unused DMXMON arbitrated interrupt vectors 
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BEG 148 
HG8141 
BB i142 
488143 
Ba8144 
#60158 
868154 
G66152 
@46153 
668154 
860168 
GHE2HB 
BaG228 
GGH246 
640244 
Baae4s 
GaB244 
AGB25H 
640253 
BEB254 
abn255 
Ban25c 
ST aS pede 
ag8264 
Bab26S 
Gba26C 
68H288 
Aha 286 
aeaecs 
BaaSag 
GH0568 
BaG7aG 
@BADCA 
on iaag 
440088 
148868 
118088 
1Z2H068 
248088 


G0 14F 


848 15F 
B68 1FF 
BG421F 
66823F 
8842493 
B4B247 
Bba24S7 


809256 
800 25F 
GO0263 
849247 
BAB26B 
94227 
QG029F 
#00 2BF 
QHg4FF 
@HOSFF 
BGRSFF 
HOBDCF 
QOUFFF 
OSFFFF 
GFFFFF 
1GFFFF 
11FFFF 
1FFFFF 
FFFFFF 


SVC operation complete interrupt request flag 
Automatic screen update completed interrupt request flag 
Keyboard interrupt request flag 

Clock interrupt request flag 

Unused DMXMON arbitrated interrupt request flags 

SVC operation complete interrupt enable flag 

Automatic screen update completed interrupt enable flag 
Keyboard interrupt enable flag 

Clock interrupt enable flag 

Unused DMXMON arbitrated interrupt enable flags 
-unused- 

Save area for data registers 

Save area for address registers & system stack pointer 
Save area for user stack pointer 

Save area for program counter 

Save area for status register 

-unused- 

DMXMON internal use flags 

Character entered from the interrupting Keyboard 
DMXMON internal use flag 

~unused- 

DMXMON internal use 

Address of system input line buffer set by SVCDFE 
Address of system output line buffer set by SVCOFB 

32 bit clock controlled by CLKON and CLKOFF SVCs 
-unused- 

Arguments to 6562 SVC processor 

Arguments from 6562 SUC processor 

Default system stack 

Default input line buffer 

Default output line buffer 

DMAMON program code 

Unused, reserved for DMXMON expansion 

-unused- available for user programs (standard Datamaver) 
-unused- available for user programs (expansion memory? 
Decoded as on-board I/0 - 

Decoded as off-board 1/0 

Not decoded 

Seven duplicates of 486086 - IFFFFF 


See ERROR MESSAGES 

Listed below are all of the error messages that can originate from DMXMON. 
In addition to these, CODOS may sometimes print its own message which can be 
recognized because CODOS errors are numbered. 


3.2.1 CONSOLE MODE MESSAGES 


<FROM> ARGUMENT MISSING OR ILLEGAL 
<TO> ARGUMENT MISSING OR ILLEGAL 
<DEST> ARGUMENT MISSING OR ILLEGAL 
<VALUE> ARGUMENT MISSING OR ILLEGAL 
<CHANNEL> ARGUMENT MISSING OR ILLEGAL 
<DEVICE> ARGUMENT MISSING OR ILLEGAL 
<FILENAME> ARGUMENT MISSING OR ILLEGAL 
CENTRY> ARGUMENT MISSING OR ILLEGAL 
€FROM> ARGUMENT GREATER THAN <TO> 

NEW FILENAME ALREADY EXISTS 

FILE NOT FOUND 

€VALUE> ARGUMENT NEGATIVE OR > $FF 
ARITHMETIC OVERFLOW 

STRING DELIMITER MISSING OR ILLEGAL 
MEMORY VERIFY FAILED AFTER SET/FILL 
DRIVE NOT OPEN 

FILE 1S LOCKED 

NOT A “.$" LOADABLE FILE 

ILLEGAL REGISTER ID 

ILLEGAL BREAKPOINT ADDRESS (MUST BE EVEN) 
TQO0 MANY BREAKPOINTS DEFINED 
ARGUMENT MISSING OR ILLEGAL 


3-2-2 EXECUTION MODE ERRORS 


When an unrecoverable error occurs during execution mode, one of the error 
messages listed below is printed followed by a printout of the register 
contents. The "UNSUCCESSFUL SVC EXECUTION" message may be preceeded by a CODOS 
error message which identifies the nature of the problem. In either case, 
DMXMON enters console mode after an execution mode error. 


%¥¥X6808@ SYSTEM CRASH - UNRECOGNIZED COMPLETION CODEX%X - Is generally caused by 
a 6880@ program that has run wild and wiped out memory. A RESET command 
should be issued to reload 68888 DMXMON. 

-CONSOLE INTERRUPT- - The INT Key was pressed during execution mode. 


XXXADDRESS ERRORXXX - Typically caused by trying to address a word or long word 
operand at an odd address. 


XXXILLEGAL INSTRUCTIONXX% - The 688808 CPU has tried to execute an undefined op 
code. 


XXXPRIVILEGE VIOLATIONX¥X - The user program has changed the privilege level to 
User and then tried to execute a privileged instruction. 


X¥X¥XNO USER VECTOR FOR TRACE INTERRUPTXXX - A trace interrupt occured but its 
vector had never been defined. 


oS 


X¥XX¥NG USER VECTOR FOR ZERO DIVIDE INTERRUPTXXX - A divison by zero was attempted 
and the zera divide vector had never been defined. 


XXXNO USER VECTOR FOR CHK INSTRUCTIONXX¥ - A CHK instruction that failed was 
executed and the CHK instruction vector had never been defined. 


XXXNQ USER VECTOR FOR TRAPYV INSTRUCTION¥X¥ - A TRAPYV instruction that failed was 
executed and the TRAFPV instruction vector had never been defined. 


X¥XNO USER VECTOR FOR EMULATOR OP CODESX¥X - The 68008 CPU has tried to execute 
an undefined op code whose first hex digit is either $A or $F and the 
emulator opcode vector had never been defined. 


¥XXNOQ USER VECTOR FOR USER TRAP INSTRUCTION¥¥¥ - A TRAP 4-15 instruction was 
executed and its vector had never been defined. 


XXXNO USER VECTOR FOR AUTOVECTOR INTERRUPTXXX - A hardware failure has caused an 
autovector interrupt, 


XEXNO USER VECTOR FOR DMXMON INTERRUPTXX% - One of the DMXMON arbitrated 
interrupts has been enabled but the associated vector was never defined, 


XEXUNIMPLEMENTED 68608 SVCX¥X - An SVC with an undefined ID was attempted. 

-BREAKPCINT- - A breakpoint was encountered during execution. 

XXXNEW SVC ATTEMPTED BEFORE PREVIOUS SVC COMPLETEX%X% - When using overlapped 1/0 
and computation, the current SVC was not completed with a TRAP 3 before 
another one was started with a TRAP 1 or TRAP 2. 

KXXUNSUCCESSFUL SVC EXECUTIONX¥X - Due to an error condition, an SVC could not 
be completed successfully. There will typically be a CODOS message before 


this message. 

¥XX63808 SYSTEM CRASH - HARDWARE BUS ERRORE¥XX - A hardware failure has caused 
the 48848 to recognize a bus error. 

5.3 LOADABLE FILE FORMAT 


Datamover memory images saved by DMXMON with the SAVE command have a default 
extension of .6 and use the following format for each memory block stored: 


BYTE NUMBER CONTENTS DESCRIPTION 

8 $B6=' 6° +80 Header byte to indicate 68888 loadable file 
1 $41='A’ Absolute block code 

2-3 $0026 Size of the block header = 32 bytes 

4-7 $40 Reserved for future use 

8-11 <from> Load address for the block 

12-15 €tod-<from>+1 Size of the block 

16-17 Centry> Entry point address (meaningful on first block) 
26-31 $08 Reserved for future use 

32-(Sizet31) €data> Saved Datamover memory image for the block 
weceee Additional blocks, if present 


Multi-byte numbers are stored in the file least significant byte first. If 
multiple blocks are stored in the file, the above format is merely repeated as 
many times as necessary. The GET command continues loading until end-of-file is 
encountered, 
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é. SAMPLE FPROGRAMS 


On the DMXMON distribution disk are three sample programs that use DMXMON 
SVCs extensively. IMAGETRANS illustrates general SVC usage, particularly those 
associated with operator dialog through the console and disk file manipulation. 
HATCOMP illustrates use of the graphic SVCs for creating drawings directly on 
the MTU-13@ screen and use of the “virtual screen" feature of DMXMON. INTKBDEMO 
illustrates an interrupt driven 68886 program using the optional interrupting 
keyboard support features of DMXMON. The main purpose of these programs is to 
illustrate how SVCs are used in typical, non-trivial programming situations. 
They also contain some generally useful 468688 subroutines including decimal 
number decoding, 32 bit square roct, and table-lookup sine and cosine. 


Both the source file (<name>.A) and object file (<name>.6) for each program 
is included on the DMXMON distribution disk. The source files are written so 
that they can be assembled using the MTU ASM or MACASM 6582 assemblers; a 68000 
assembler is not required. Use the following procedure if you wish to alter one 
of the programs and re-assemble it: 


1. Be sure the files OP68006.A and SVC68406.A are on the disk along with the 
source. 


2. After making the desired changes with the editor, assemble the program in the 
usual manner using either ASM or MACASM. 


3. While in CODOS, load the object file into Datamover memory with a GET command 
(a .BANK 2 statement is included in the source so that it will automatically 
be loaded into Bank 2 which is low Datamover memory). 


4. Execute a GETLOC command to determine where the program has loaded. 
5S. Start up DMXMON by entering DMXMON and a carriage return. 


6. SAVE the program from DMXMON so that it will be in DMXMON loadable format 
instead of CODOS loadable format. The default file extension is .6. 


7. You may delete the CODOS loadable object file produced by the assembler now 
if you wish. 


8. The re-assembled program may be executed from DMXMON by simply typing its 
name. 


a4 IMAGETRANS 


This program illustrates use of the inline message, line input, record 
input, record output, file assignment, and other character oriented and file 
handling SVCs. It incorporates extensive error checking as an example of how 
that is performed as well. Its actual function is to convert a screen dump disk 
file which is A pixels wide and B pixels high into a similar file B pixels wide 
and A pixels high. This may actually be useful for rotating images that will be 
printed by the MTU word processor, WORDPIC. 


To start the program, just type its name in response to a DMXMON prompt. It 
will clear the screen, identify itself, and ask for a file name. The file must 
be a memory image, either of 6562 memory or of 68668 memory, must be on a 
non-write protected disk, and must be unlocked. All of these requirements are 
checked by the program and an appropriate message printed if there is a problem. 
It then asks for the dimensions of the image stored in the file. Each dimension 
should be a multiple of 8. Following this, the entire file is read into memory 
rowwise and then rewritten columnwise. A 1624x1824 image file (128K bytes) 
requires about 2 minutes to transpose. 


6.2 HAT COMP 


This program illustrates the use of graphics oriented SVCs. It both draws 
directly on the MTU-138 screen using SMOVE, SDRAW, and SVEC SVCs, and also draws 
on a "virtual screen" in 68066 memory and uses the window copy SVCs to transfer 
to the “13@ screen. It also illustrates a number of programming and operator 
interaction techniques and contains some useful math oriented subroutines. Its 
actual function is to compute the famous MTU HAT image on a 1024 by 1024 grid 
and allow the operator to interactively move a smaller window around on this 
grid to view portions of the image. With a suitable printer (such as the NEC 
PC-4823) and program (such as WORDPIC’s PRINT program), the image may be printed 
in its entirety on paper. 


To run the program, simply type its name, HATCOMP, in repsonse to a DMXMON 
prompt. It will clear the MTU-13@ screen, draw two rectangles at the left, and 
immediately begin computation of the hat image. The larger rectangle represents 
the full 1624x1824 virtual image plane (1/8 size) and the smaller rectangle 
represents the currently visible window. Even while computation is taking 
place, you may move the window around with the cursor arrow Keys. Movement is 
in steps of 8 pixels. If the shift Key is held down, movement is in steps of 64 
pixels. After approximately 18 minutes, the completed image will be copied into 
the large rectangle at the left for reference. The window may still be moved 
around. To halt the program, press the INT Key. To save the image on disk for 
printing Cor processing by the IMAGETRANS program), SAVE memory from 20000 
through 3FFFF while in DMXMON. 


6.3 INTKBDEMO 


This program illustrates programming techniques for the interrupting 
Keyboard feature of DMXMON. The program itself simply displays whatever is 
typed but Keyboard input is queued and Keyboard scanning is done with an "N-key 
rollover" algorithm. This means that keystrokes will never be lost no matter 
what the screen is doing or how fast the operator types or how many keys (within 
reason) are down simultaneously. 


To start the program, type its name, INTKBDEMO, in response to a DMXMON 
prompt. The screen will be cleared and the cursor will appear in the home 
position flashing faster than normal. You can test the queveing function by 
pressing a number of Keys at once (such as all of the number Keys) and noting 
that they are all recognized although the exact order may be unpredictable. You 
may also try a number of cursor downs to queue up a few screen scrolls and note 
that subsequent typed input is not lost although there will be a delay before it 
is displayed. The program may be stopped by entering cntl/Z2. If it is stopped 
with the INT Key, the interrupting Keyboard will still be enabled and you will 
get two clicks for each Keystroke! Enter a RESET command to clear this 
condition. 


96 


